Re: calling flush_scheduled_work()

[Tim Hockin <thockin@sun.com>]

On Fri, Mar 12, 2004 at 06:19:14PM -0500, Trond Myklebust wrote:
> Ewww.... That's saying "I'm just going to ignore the problem and pretend
> I can continue". At least the hang will tell you that there *is* a
> problem and points to where it is happening.

Well, it needs to be non-silent.  Whether that is a BUG() or a badness or a
panic..

> > In short, it's dubious that ANYONE call flush_scheduled_work() on a
> > workqueue that they don't own.
> 
> Huh? You're saying that just because work has been scheduled on some
> third party thread, you should not be allowed to wait on completion of
> that work? That is a clearly unreasonable statement... Imagine doing
> even memory allocation in such an environment...

Waiting for completion of your work is one thing.  But you can't know what
else has been scheduled.  In this case RPC doesn't know that our work is
calling it.  By waiting for ALL work, it is assuming (silently) that it will
never be called from a keventd.

Either that assumption is true, in which case there needs to be a BUG and a
way out, or that assumption is false.  I'd like to believe that the
assumption is false.

> The *real* problem here is that mput() is being run from keventd, and is
> triggering code that was assumed to be running from an ordinary process
> context. Let's concentrate on fixing that...

Well, we did fix it in a different way.  I just wanted to bring this up as
something that warrants at least a BUG().  But a BUG() and deadlock is
almost a panic().

So if mntput() just CAN NOT be called from keventd, that is a fine answer,
but something should be written about that.  And all the other things that
can not be called from keventd.

-- 
Tim Hockin
Sun Microsystems, Linux Software Engineering
thockin@sun.com
All opinions are my own, not Sun's