Re: workqueue thing

From: Linus Torvalds
Date: Tue Dec 22 2009 - 13:31:18 EST

On Tue, 22 Dec 2009, Peter Zijlstra wrote:
> Which in turn would imply we cannot carry fwd the current lockdep
> annotations, right?
> Which means we'll be stuck in a situation where A flushes B and B
> flushes A will go undetected until we actually hit it.

No, lockdep should still work. It just means that waiting for an
individual work should be seen as a matter of only waiting for the locks
that work itself has done - rather than waiting for all the locks that any
worker has taken.

And the way the workqueue lockdep stuff is done, I'd assume this just
automatically fixes itself when rewritten.

> Where exactly does the tty thing live in the code?

I think I worked around it all, but I cursed the workqueues while I did
it. The locking problem is tty->ldisc_mutex vs flushing the ldisc buffers.
The flushing itself doesn't even care about the ldisc_mutex, but if it
happens to be behind a the hangup work - which does care about that mutex
- you still can't wait for it.

Happily, it turns out that you can synchronously _cancel_ the damn thing
despite this problem, because the cancel can take it off the list if it is
waiting for something else (eg another workqueue entry in front of it),
and if it's actively running we know that it's not blocked waiting for
that hangup work that needs the lock, so for that particular case we can
even wait for it to finish running - even if we couldn't do that in

And I
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at