On Thu, 27 Feb 2014 15:32:42 -0800 Andrew Morton [off-list ref]
wrote:

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

quoted

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).

I was hoping that Al would step in with an answer, but I got impatient had
had a look around myself.

I found

commit 99b76233803beab302123d243eea9e41149804f3
Author: Alexey Dobriyan [off-list ref]
Date:   Wed Mar 25 22:48:06 2009 +0300

    proc 2/2: remove struct proc_dir_entry::owner
    


which references

https://bugzilla.kernel.org/show_bug.cgi?id=12454

which seems to suggest that we used to try to do as you suggest but it was
racy and would be a lot of work to "fix". The chosen solution was to only
'get' the module during read/write, not just while the /proc file is open.

NeilBrown