From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:38660 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1725798AbeI3IbV (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Sun, 30 Sep 2018 04:31:21 -0400
Date: Sun, 30 Sep 2018 03:00:14 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: NeilBrown <neilb@suse.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] bloody odd logics in md_exit()
Message-ID: <20180930020010.GJ32577@ZenIV.linux.org.uk>
References: <20180929033334.GG32577@ZenIV.linux.org.uk>
 <87k1n3gb2s.fsf@notabene.neil.brown.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87k1n3gb2s.fsf@notabene.neil.brown.name>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sun, Sep 30, 2018 at 09:04:11AM +1000, NeilBrown wrote:

> Hi Al,
>  I don't think wake_up_all() does remove anything from the queue.
>  It simply wakes up the various processes that are waiting.
>  They remain on the queue until they call remove_wait_queue(), which
>  could be delayed arbitrarily.
>  If it was delayed until after the module was unloaded and
>  "md_event_waiters" no longer existed, the unlink attempt would cause an
>  invalid memory access.
> 
>  I think your approach for simplify the code would only work if
>  md_event_waiters could be moved out of the module, or if some global
>  wait_queue could be used instead.
>  Maybe we could use bit_waitqueue(NULL,0) (rather an ugly hack).
>  Maybe we could export a general-purpose waitqueue for modules to use.
>  Maybe procfs could export something??
> 
>  I agree that we can remove md_unloading, by moving remove_proc_entry()
>  before the wakeup.  I'm not yet convinced that we can remove the wakeup
>  loop.
>  
>  Or am I missing something else here?

You are not, unfortunately; I plead a bad braino.  remove_wait_queue() will,
indeed, happen only when we get around to poll_freewait().  Bugger...
That's a problem, and I'm not at all sure that it's only md that needs to
be concerned with it.  And it's not just procfs either - debugfs users have
exact same problem if they have ->poll() in their file_operations...