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 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/