linux-kernel - Re: [PATCH 13/26] locking: Add non-fatal spin lock assert

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]

Date:	Wed, 10 Sep 2014 11:34:52 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, Jiri Slaby <jslaby@...e.cz>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 13/26] locking: Add non-fatal spin lock assert

On Wed, Sep 10, 2014 at 10:45:33AM -0400, Peter Hurley wrote:
> On 09/10/2014 09:08 AM, Peter Zijlstra wrote:
> > On Wed, Sep 10, 2014 at 07:02:10AM -0400, Peter Hurley wrote:
> >> On 09/04/2014 01:14 AM, Ingo Molnar wrote:
> >>>
> >>> * Peter Zijlstra <peterz@...radead.org> wrote:
> >>>
> >>>> On Wed, Sep 03, 2014 at 10:50:01AM -0400, Peter Hurley wrote:
> >>>>> So a lockdep-only assert is unlikely to draw attention to existing bugs,
> >>>>> especially in established drivers.
> >>>>
> >>>> By the same logic lockdep will not find locking errors in established
> >>>> drivers.
> >>>
> >>> Indeed, this patch is ill-advised in several ways:
> >>>
> >>>   - it extends an API variant that we want to phase
> >>>
> >>>   - emits a warning even if say lockdep has already emitted a
> >>>     warning and locking state is not guaranteed to be consistent. 
> >>>
> >>>   - makes the kernel more expensive once fully debugged, in that
> >>>     non-fatal checks are unconditional.
> >>
> >> Ok.
> >>
> >> One thing: I'm not seeing how lockdep_assert_held() switches off once
> >> the warning has been emitted? Is the caller expected to construct their
> >> own _ONCE tags?
> > 
> > Indeed, it does not do that. I suppose you can add
> > lockdep_assert_held_once() or somesuch if you think the once thing is
> > important.
> 
> Ok, will do.
> 
> On 09/04/2014 01:14 AM, Ingo Molnar wrote:
> > Also please submit locking related patches as standalone series 
> > to the locking subsystem, not embedded in an unrelated series.
> 
> Ok, but how will Greg know when to take the series that depends on
> this change, if the locking change is submitted separately?

 Cc: me on those changes, and I can track what happens with the tip tree
 where these would show up.

Or wait a release cycle, that also is an easy way.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/