[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B26C95A.8000708@kernel.org>
Date: Tue, 15 Dec 2009 08:25:14 +0900
From: Tejun Heo <tj@...nel.org>
To: Alan Stern <stern@...land.harvard.edu>
CC: Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Warn people about flush_scheduled_work()
Hello,
On 12/15/2009 08:14 AM, Alan Stern wrote:
>> I think both problems can be detected by lockdep, right? So, they
>> aren't that difficult to detect.
>
> Maybe they can, now. It used to be they couldn't.
I think they can now. Workqueue workers acquire pseudo lock known to
lockdep around execution of a work function and flush_workqueue()
grabs and releases the pseudo lock too, so both are known to lockdep.
> However, lockdep doesn't help much -- it tells you the cause of the
> deadlock but it doesn't prevent the deadlock from occurring. The
> programmer has to do this, by avoiding flush_scheduled_work(). I guess
> that could be added to the comment.
As lockdep computes deadlocks from all possible combinations, it
usually detects deadlocks pretty quickly during devel cycle, so it
doesn't prevent them from happening but still helps a lot.
>> Yeah, recommending more work-specific constructs definitely would be
>> better. It's bad that we can't recommend the use of flush_work() as
>> it doesn't do cross-cpu flushing. Maybe that needs explanation too.
>
> I'll do my comments, and you can do yours. :-)
Fair enough. :-)
> Should these changes go through Andrew Morton? Or can you take them?
I already have a tree set up for workqueue changes, so I guess I can
take them.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists