[lkml]   [2007]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC/PATCH] debug workqueue deadlocks with lockdep
    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!

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2007-07-04 15:59    [W:0.021 / U:8.432 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site