Messages in this thread | | | Subject | Re: calling flush_scheduled_work() | From | Trond Myklebust <> | Date | Fri, 12 Mar 2004 18:19:14 -0500 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |