On Fri, 28 Feb 2014 10:07:57 +1100 NeilBrown [off-list ref] wrote:

On Thu, 27 Feb 2014 13:51:25 -0800 Andrew Morton [off-list ref]
wrote:

quoted

On Fri, 28 Feb 2014 08:34:43 +1100 NeilBrown [off-list ref] wrote:

quoted

On Thu, 27 Feb 2014 12:58:07 -0800 Andrew Morton [off-list ref]
wrote:

quoted

On Thu, 27 Feb 2014 17:24:45 +1100 NeilBrown [off-list ref] wrote:

quoted

If poll or select is waiting on /proc/mdstat when md-mod is unloaded
an oops will ensure when the poll/select completes.

This is because the wait_queue_head which is registered with poll_wait()
is local to the module and no longer exists when the poll completes and
detaches that wait_queue_head (in poll_free_wait -> remove_wait_queue).

To fix this we need the wait_queue_head to have (at least) the same life
time as the proc_dir_entry.  So this patch places it in that structure.

We:
  - add pde_poll_wait to struct proc_dir_entry
  - call poll_wait() passing this when poll() is called on the proc file
  - export a function proc_wake_up which will call wake_up() on pde_poll_wait

and make use of all that in md.c

This sounds wrong.  If a userspace process is waiting on
md_event_waiters then the md module is "busy" and the rmmod attempt
should fail?

Al Viro says "no" quite firmly.

I think the core argument is that

  rmmod md-mod < /proc/mdstat

would deadlock.

Well, only if the rmmod hangs around waiting for the module to go idle.
I'm thinking rmmod should fail.  EBUSY.

This?  What happens if we just fail the rmmod when the module is busy
(which it is).