On Mon, May 22, 2023 at 5:52 PM David Rientjes <rientjes@xxxxxxxxxx> wrote:
>
> Right now kernel.panic_on_warn can either be 0 or 1. We can keep the
> lowest bit to be "panic on all warnings" and then bit-1 as "panic on debug
> VM warnings." When CONFIG_DEBUG_VM is enabled, set the new bit by
> default so there's no behavior change.
So right now CONFIG_DEBUG_VM being off means that there's nothing at
all - not just no output, but also no code generation.
I don't think CONFIG_DEBUG_VM in itself should enable that bit-1 behavior.
That may be what *you* as a VM person wants, but VM people are not
exactly the common case.
So I think we've got several cases:
(a) the "don't even build it" case (CONFIG_DEBUG_VM being off)
(b) the "build it, and it is a WARN_ON_ONCE()" case
(c) the *normal* "panic_on_warn=1" case, which by default would panic
on all warnings, including any warnings from CONFIG_DEBUG_VM
(d) the "VM person" case, which might not panic on normal warnings,
but would panic on the VM warnings.
and I think the use-cases are for different classes of kernel use:
(a) is for people who disable debugging code until they feel it is
needed (which I think covers a lot of kernel developers - I certainly
personally tend to not build with debug support unless I'm chasing
some issue down)
(b) would probably be most distros - enable the warning so that the
distro can report it, but try not to kill the machine of random people
(c) would be most cloud use cases, presumably together with reboot-on-panic
(d) would be people who are actual VM developers, and basically want
the *current* behavior of VM_BUG_ON() with a machine that stops
and I think (d) is the smallest set of cases of all, but is the one
you're personally interested in.
Linus
Linus
