lkml.org 
[lkml]   [2009]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2009-12-15 00:27    [W:0.065 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site