linux-kernel - Re: [PATCH] lockdep: Panic on warning if panic_on

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] [day] [month] [year] [list]

Date:   Mon, 22 Aug 2022 14:16:08 +0200
From:   Vincent Whitchurch <vincent.whitchurch@...s.com>
To:     Boqun Feng <boqun.feng@...il.com>
CC:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
        kernel <kernel@...s.com>, Waiman Long <longman@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lockdep: Panic on warning if panic_on_warn is set

On Sat, Aug 20, 2022 at 07:18:37AM +0200, Boqun Feng wrote:
> > I'm not trying to obtain a kdump in this case.  I test device drivers
> > under UML[0] and I want to make the tests stop and fail immediately if
> > the driver triggers any kind of problem which results in splats in the
> > log.  I achieve this using panic_on_warn, panic_on_taint, and oops=panic
> > which result in a panic and an error exit code from UML.
> > 
> > [0] https://lore.kernel.org/lkml/20220311162445.346685-1-vincent.whitchurch@axis.com/
> > 
> > For lockdep, without this patch, I would be forced to parse the logs
> > after each test to determine if the test trigger a lockdep splat or not.
> 
> In that case, would a standard line with every lockdep warning help? For
> example:
> 
> [...] A LOCKDEP issue detected.
> 
> Two reasons I don't think making lockdep warning as panic is a good
> idea:
> 
> * We don't know what other CIs expect, given today lockdep doesn't panic
>   with panic_on_warn, this patch is a change of behaviors to them, and
>   it may break their setups/scripts.

Perhaps we could add a module parameter instead, so that the behaviour
can be enabled with lockdep.panic=1 or similar?  Then no existing setups
will be affected.

> * As I said, lockdep warnings are different than other warnings, and
>   panicking doesn't provide more information for debugging.
> 
> So I think an extra line helping scripts to parse may be better.
> 
> Work for you?

For my use case, the extra line isn't needed.  If I must parse the logs,
I can already do it with the existing prints.  But I'm trying to avoid
having to parse the logs altogether.