Skip to content
  1. Sep 10, 2011
    • NeilBrown's avatar
      md/raid1,10: Remove use-after-free bug in make_request. · 079fa166
      NeilBrown authored 
      A single request to RAID1 or RAID10 might result in multiple
requests if there are known bad blocks that need to be avoided.

To detect if we need to submit another write request we test:
 	if (sectors_handled < (bio->bi_size >> 9)) {

However this is after we call **_write_done() so the 'bio' no longer
belongs to us - the writes could have completed and the bio freed.

So move the **_write_done call until after the test against
bio->bi_size.

This addresses https://bugzilla.kernel.org/show_bug.cgi?id=41862



Reported-by: default avatarBruno Wolff III <bruno@wolff.to>
Tested-by: default avatarBruno Wolff III <bruno@wolff.to>
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      079fa166
    • NeilBrown's avatar
      md/raid10: unify handling of write completion. · 19d5f834
      NeilBrown authored 
      

A write can complete at two different places:
1/ when the last member-device write completes, through
   raid10_end_write_request
2/ in make_request() when we remove the initial bias from ->remaining.

These two should do exactly the same thing and the comment says they
do, but they don't.

So factor the correct code out into a function and call it in both
places.  This makes the code much more similar to RAID1.

The difference is only significant if there is an error, and they
usually take a while, so it is unlikely that there will be an error
already when make_request is completing, so this is unlikely to cause
real problems.

Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      19d5f834
    • NeilBrown's avatar
      Avoid dereferencing a 'request_queue' after last close. · 94007751
      NeilBrown authored 
      On the last close of an 'md' device which as been stopped, the device
is destroyed and in particular the request_queue is freed.  The free
is done in a separate thread so it might happen a short time later.

__blkdev_put calls bdev_inode_switch_bdi *after* ->release has been
called.

Since commit f758eeab


bdev_inode_switch_bdi will dereference the 'old' bdi, which lives
inside a request_queue, to get a spin lock.  This causes the last
close on an md device to sometime take a spin_lock which lives in
freed memory - which results in an oops.

So move the called to bdev_inode_switch_bdi before the call to
->release.

Cc: Christoph Hellwig <hch@lst.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Acked-by: default avatarWu Fengguang <fengguang.wu@intel.com>
Cc: stable@kernel.org
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      94007751
  3. Aug 31, 2011
    • NeilBrown's avatar
      md/raid5: fix a hang on device failure. · 43220aa0
      NeilBrown authored 
      

Waiting for a 'blocked' rdev to become unblocked in the raid5d thread
cannot work with internal metadata as it is the raid5d thread which
will clear the blocked flag.
This wasn't a problem in 3.0 and earlier as we only set the blocked
flag when external metadata was used then.
However we now set it always, so we need to be more careful.

Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      43220aa0
  5. Aug 30, 2011
  7. Aug 25, 2011
  9. Aug 24, 2011
  11. Aug 23, 2011
  13. Aug 22, 2011
  15. Aug 21, 2011
  17. Aug 20, 2011