Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks
From: Byungchul Park
Date: Fri Aug 25 2017 - 11:49:32 EST
On Fri, Aug 25, 2017 at 10:34 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> 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@xxxxxxx>
>> 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.
Well.. I don't think it's the same level currently. But, I can make it with some
modification. I expect the wq code to become much simpler.
> However, how would it distinguish things like flushing another work
I think it must be distinguished with what it actually waits for, e.i.
completion
variables instead of work or wq. I will make it next week and let you know.
> item on a workqueue w/ max_active of 1?
I will answer it wrt max_active == 1 next week. I need to review wq code.
--
Thanks,
Byungchul