RE: crash: write_sb_page walks mddev.disks without holding reconfig_mutex

[Neil Brown <neilb@suse.de>]

On Monday July 21, Nate.Dailey@stratus.com wrote:
> Quick update... I've applied your patch to the kernel I'm using. There
> were a few differences... for example, md_delayed_delete doesn't exist
> in my kernel (so I added it).
> 
> Unfortunately, I'm hitting a deadlock, and it looks like md_delayed_work
> is at fault. Seems that in at least one case, code which holds the
> inode_lock is interrupted, at which point the md_delayed_delete code
> gets to run. He ends up needing the inode_lock too, and we're stuck.

Yes.... I noticed yesterday that there was a problem with that patch.
calling md_delayed_delete with call_rcu just isn't right.
md_delayed_delete needs to get a mutex, and call_rcu calls things in a
context where mutexes aren't allowed.  The problem you are seeing has
exactly the same cause.

So I've changed it to:
  call synchronise_rcu() to handle the RCU side, and
  restore the use of schedule_work to run md_delayed delete.
so unbind_rdev_from_array now ends.
	synchronize_rcu();
	INIT_WORK(&rdev->del_work, md_delayed_delete);
	kobject_get(&rdev->kobj);
	schedule_work(&rdev->del_work);

You can see the submitted version of the full patch at 

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4b80991c6cb9efa607bc4fd6f3ecdf5511c31bb0

If you can test that (with appropriate revisions to apply to your
kernel) I'd really appreciate it.

Thanks,
NeilBrown