Re: [PATCH] lockdep: Panic on warning if panic_on_warn is set

[Vincent Whitchurch <vincent.whitchurch@axis.com>]

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.