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: <5410640D.8010903@hurleysoftware.com>
Date:	Wed, 10 Sep 2014 10:45:33 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.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 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?

Regards,
Peter Hurley
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ