md: Protect access to mddev->disks list using RCU
authorNeilBrown <neilb@suse.de>
Mon, 21 Jul 2008 07:05:25 +0000 (17:05 +1000)
committerNeilBrown <neilb@suse.de>
Mon, 21 Jul 2008 07:05:25 +0000 (17:05 +1000)
commit4b80991c6cb9efa607bc4fd6f3ecdf5511c31bb0
tree5e2ba7d509af245c29bdf04b00960cc367972c44
parentf2ea68cf42aafdd93393b6b8b20fc3c2b5f4390c
md: Protect access to mddev->disks list using RCU

All modifications and most access to the mddev->disks list are made
under the reconfig_mutex lock.  However there are three places where
the list is walked without any locking.  If a reconfig happens at this
time, havoc (and oops) can ensue.

So use RCU to protect these accesses:
  - wrap them in rcu_read_{,un}lock()
  - use list_for_each_entry_rcu
  - add to the list with list_add_rcu
  - delete from the list with list_del_rcu
  - delay the 'free' with call_rcu rather than schedule_work

Note that export_rdev did a list_del_init on this list.  In almost all
cases the entry was not in the list anymore so it was a no-op and so
safe.  It is no longer safe as after list_del_rcu we may not touch
the list_head.
An audit shows that export_rdev is called:
  - after unbind_rdev_from_array, in which case the delete has
     already been done,
  - after bind_rdev_to_array fails, in which case the delete isn't needed.
  - before the device has been put on a list at all (e.g. in
      add_new_disk where reading the superblock fails).
  - and in autorun devices after a failure when the device is on a
      different list.

So remove the list_del_init call from export_rdev, and add it back
immediately before the called to export_rdev for that last case.

Note also that ->same_set is sometimes used for lists other than
mddev->list (e.g. candidates).  In these cases rcu is not needed.

Signed-off-by: NeilBrown <neilb@suse.de>
drivers/md/bitmap.c
drivers/md/md.c
include/linux/raid/md_k.h