Re: calling flush_scheduled_work()

[Trond Myklebust <trond.myklebust@fys.uio.no>]

På fr , 12/03/2004 klokka 17:38, skreiv Tim Hockin:
> That just divides up the problem, but doesn't solve it.  The simplest would
> be to print a badness and somehow get out of the flush.  Then anyone who is
> triggering the corner case (us, in this case) can just solve it ourselves.
> It's not pretty.

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.

If I understood your description of where it is happening, then in this
case, continuing is likely to lead to an Oops later when all those open
RPC up/downcall pipes find that their parent directory has disappeared
from underneath them.

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

I agree that we need to identify and solve the deadlocking problems, but
let's not start constricting developers with completely arbitrary rules.

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

Cheers,
  Trond