Messages in this thread | | | Date | Mon, 22 Aug 2022 14:16:08 +0200 | From | Vincent Whitchurch <> | 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.
| |