[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170825133442.GU491396@devbig577.frc2.facebook.com>
Date: Fri, 25 Aug 2017 06:34:43 -0700
From: Tejun Heo <tj@...nel.org>
To: Byungchul Park <byungchul.park@....com>
Cc: johannes.berg@...el.com, peterz@...radead.org, mingo@...nel.org,
tglx@...utronix.de, linux-kernel@...r.kernel.org,
kernel-team@....com
Subject: Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks
On Fri, Aug 25, 2017 at 05:41:03PM +0900, Byungchul Park wrote:
> Hello all,
>
> This is _RFC_.
>
> I want to request for comments about if it's reasonable conceptually. If
> yes, I want to resend after working it more carefully.
>
> Could you let me know your opinions about this?
>
> ----->8-----
> From 448360c343477fff63df766544eec4620657a59e Mon Sep 17 00:00:00 2001
> From: Byungchul Park <byungchul.park@....com>
> Date: Fri, 25 Aug 2017 17:35:07 +0900
> Subject: [RFC] workqueue: remove manual lockdep uses to detect deadlocks
>
> We introduced the following commit to detect deadlocks caused by
> wait_for_completion() in flush_{workqueue, work}() and other locks. But
> now LOCKDEP_COMPLETIONS is introduced, such works are automatically done
> by LOCKDEP_COMPLETIONS. So it doesn't have to be done manually anymore.
> Removed it.
I'm not following lockdep development, so can't really comment but if
you're saying that wq can retain the same level of protection while
not having explicit annotations, conceptually, it's of course great.
However, how would it distinguish things like flushing another work
item on a workqueue w/ max_active of 1?
Thanks.
--
tejun
Powered by blists - more mailing lists