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: <20170905081950.GT3240@X58A-UD3R>
Date:   Tue, 5 Sep 2017 17:19:50 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "tj@...nel.org" <tj@...nel.org>,
        "johannes.berg@...el.com" <johannes.berg@...el.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "oleg@...hat.com" <oleg@...hat.com>,
        "david@...morbit.com" <david@...morbit.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kernel-team@....com" <kernel-team@....com>
Subject: Re: [PATCH 3/3] lockdep: Remove unnecessary acquisitions wrt
 workqueue flush

On Tue, Sep 05, 2017 at 04:36:18PM +0900, �ں�ö/���ӿ�����/SW Platform(��)AOT��(byungchul.park@....com) wrote:
> > -----Original Message-----
> > From: Peter Zijlstra [mailto:peterz@...radead.org]
> > Sent: Tuesday, September 05, 2017 4:26 PM
> > To: Byungchul Park
> > Cc: tj@...nel.org; johannes.berg@...el.com; mingo@...nel.org;
> > tglx@...utronix.de; oleg@...hat.com; david@...morbit.com; linux-
> > kernel@...r.kernel.org; kernel-team@....com
> > Subject: Re: [PATCH 3/3] lockdep: Remove unnecessary acquisitions wrt
> > workqueue flush
> > 
> > On Tue, Sep 05, 2017 at 11:29:14AM +0900, Byungchul Park wrote:
> > 
> > > Also, lock_map_acquire() in process_one_work() is too strong for that
> > > purpose. lock_map_acquire_might() is enough. Replaced it.
> > 
> > NAK!! traditional annotations are superior to cross-release. They are not
> > timing dependent.
> 
> You seem to mis-understand this. This also make them timing independent.
> I also agree that we need timing independent report in workqueue code.
> That's actually why I propose this patch.
> 
> I just tried to do it in a right way.

Adding insufficient comments seems to lead to mis-understand what
lock_map_acquire_might() does. I will enhance it. (And might need to
rename it to a better one as you pointed out in another reply.)

I introduced it to give a hint to lockdep that "It's not actual
acquisition but pseudo one, informing that the context might be the
commit context" so that lockdep can report warnings at the real time
as current code does.

This hint is useful to report run time deadlocks, timing independently,
but not need to be considered on commit. And the hint should be relaxed
as far as possible. I just did that.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ