On Wed, 2007-07-04 at 16:52 +0400, Oleg Nesterov wrote: > Yes. And no other work (except a barrier) can run before the caller of > wait_on_work() is woken. Alright, thanks. Yes, then what you proposed makes a lot of sense, I'll implement it. > Aha, now I see where I was confused. Yes, we can't avoid the false positives > with flush_workqueue(). > > I hope this won't be a problem, because almost every usage of flush_workqueue() > is pointless nowadays. So even if we have a false positive, it probably > means the code needs cleanups anyway. > > But see below, [...] > If you are going to do this, may I suggest you to make 2 separate patches? > Exactly because we can't avoid the false positives with flush_workqueue(), > it would be nice if we have an option to revert the 2-nd patch if there are > too many false positives (I hope this won't happen). I've run this patch on my system for a few days now and only seen exactly one warning; however, it's *not* actually a *false* positive, it's a positive but it's also perfectly possible to deadlock if the system is loaded more than one work item is stuck on the workqueue for some reason. Say A takes L1 and B runs without locks, and then you flush the workqueue under L1; you'll get a real deadlock when both A and B are actually scheduled to run! johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
