linux-kernel - Re: [patch] mm, debug: allow suppressing panic on CONFIG_DEBUG

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wi6L6yZnGCYVEmLgQY+KEHNsAW2V69mfdUCMk4qS=GnKA@mail.gmail.com>
Date:   Mon, 22 May 2023 18:47:37 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Rientjes <rientjes@...gle.com>
Cc:     David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...nel.org>, Alex Shi <alexs@...nel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Matthew Wilcox <willy@...radead.org>,
        Alexander Duyck <alexanderduyck@...com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch] mm, debug: allow suppressing panic on CONFIG_DEBUG_VM checks

On Mon, May 22, 2023 at 5:52 PM David Rientjes <rientjes@...gle.com> 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