linux.git/drivers/md, branch v2.6.21.7

dm crypt: fix remove first_clone

2007-08-04T16:10:24+00:00

Get rid of first_clone in dm-crypt

This gets rid of first_clone, which is not really needed.  Apparently, cloned
bios used to share their bvec some time way in the past - this is no longer
the case.  Contrarily, this even hurts us if we try to create a clone off
first_clone after it has completed, and crypt_endio has destroyed its bvec.

Signed-off-by: Olaf Kirch 
Signed-off-by: Alasdair G Kergon 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

dm crypt: fix avoid cloned bio ref after free

2007-08-04T16:10:24+00:00

Do not access the bio after generic_make_request

We should never access a bio after generic_make_request - there's no guarantee
it still exists.

Signed-off-by: Olaf Kirch 
Signed-off-by: Alasdair G Kergon 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

dm crypt: fix call to clone_init

2007-08-04T16:10:24+00:00

Call clone_init early

We need to call clone_init as early as possible - at least before call
bio_put(clone) in any error path.  Otherwise, the destructor will try to
dereference bi_private, which may still be NULL.

Signed-off-by: Olaf Kirch 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

dm crypt: disable barriers

2007-08-04T16:10:24+00:00

Disable barriers in dm-crypt because of current workqueue processing can
reorder requests.

This must be addresed later but for now disabling barriers is needed to
prevent data corruption.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

md: Fix bug in error handling during raid1 repair.

2007-08-04T16:10:23+00:00

If raid1/repair (which reads all block and fixes any differences
it finds) hits a read error, it doesn't reset the bio for writing
before writing correct data back, so the read error isn't fixed,
and the device probably gets a zero-length write which it might
complain about.

Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

md: Fix two raid10 bugs.

2007-08-04T16:10:23+00:00

1/ When resyncing a degraded raid10 which has more than 2 copies of each block,
  garbage can get synced on top of good data.

2/ We round the wrong way in part of the device size calculation, which
  can cause confusion.

Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] md: Don't write more than is required of the last page of a bitmap

2007-06-11T18:36:44+00:00

It is possible that real data or metadata follows the bitmap
without full page alignment.
So limit the last write to be only the required number of bytes,
rounded up to the hard sector size of the device.

Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] md: Avoid overflow in raid0 calculation with large components.

2007-06-11T18:36:44+00:00

If a raid0 has a component device larger than 4TB, and is accessed on
a 32bit machines, then as 'chunk' is unsigned lock,
   chunk << chunksize_bits
can overflow (this can be as high as the size of the device in KB).
chunk itself will not overflow (without triggering a BUG).

So change 'chunk' to be 'sector_t, and get rid of the 'BUG' as it becomes
impossible to hit.

Cc: "Jeff Zheng" 
Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] md: Avoid a possibility that a read error can wrongly propagate through md/raid1 to a filesystem.

2007-05-23T21:32:48+00:00

When a raid1 has only one working drive, we want read error to
propagate up to the filesystem as there is no point failing the last
drive in an array.

Currently the code perform this check is racy.  If a write and a read
a both submitted to a device on a 2-drive raid1, and the write fails
followed by the read failing, the read will see that there is only one
working drive and will pass the failure up, even though the one
working drive is actually the *other* one.

So, tighten up the locking.

Signed-off-by: Neil Brown 
Signed-off-by: Chris Wright

[PATCH] md: fix calculation for size of filemap_attr array in md/bitmap

2007-04-12T22:31:42+00:00

If 'num_pages' were ever 1 more than a multiple of 8 (32bit platforms)
or of 16 (64 bit platforms).  filemap_attr would be allocated one
'unsigned long' shorter than required.  We need a round-up in there.

Signed-off-by: Neil Brown 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds