lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANrsvROrv_dAd14BB+HHnZhK5vrVet+nZu0+7XHhZ9TEARy50Q@mail.gmail.com>
Date:   Mon, 28 Aug 2017 19:53:02 +0900
From:   Byungchul Park <max.byungchul.park@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Byungchul Park <byungchul.park@....com>, Tejun Heo <tj@...nel.org>,
        johannes.berg@...el.com, Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kernel-team@....com
Subject: Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks

On Mon, Aug 28, 2017 at 3:55 PM, Peter Zijlstra <peterz@...radead.org> 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@....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.
>>
>
> No.. the existing annotation is strictly better because it will _always_
> warn. It doesn't need to first observe things just right.

Right. That is exactly why I replied to TJ like:

https://lkml.org/lkml/2017/8/25/490

-- 
Thanks,
Byungchul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ