From: Michal Hocko <mhocko@suse.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, David Hildenbrand <david@redhat.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH] mm: implement "memory.oops_if_bad_pte=1" boot option
Date: Thu, 10 Jul 2025 20:29:14 +0200 [thread overview]
Message-ID: <aHAGeikybkJrPp6Y@tiehlicka> (raw)
In-Reply-To: <5242fca8-4a17-4ff8-a624-08778fc64f19@lucifer.local>
On Thu 10-07-25 18:02:07, Lorenzo Stoakes wrote:
> OK I wasn't clear enough I guess - NAK.
Completely Agreed!
Because....
> This is not upstreamable, nor anything like it.
>
> On Thu, Jul 10, 2025 at 07:57:00PM +0300, Alexey Dobriyan wrote:
> > On Thu, Jul 10, 2025 at 05:16:52PM +0100, Lorenzo Stoakes wrote:
[...]
> > > You seem to be using BUG_ON() to _maybe_ cause a panic, maybe not, but by
> > > doing this you're inferring that there's unrecoverable system instability,
> > > which isf clearly not the case.
.... of exactly this. I believe we have already/finally established that
BUG_ON (not even VM_BUG_ON) is a sensible debugging tool. In this
particular case it is not even clear when the page table got corrupted
and it could have happened loong before we notice that so crash dumping
right away doesn't really guarantee anything.
So if this really helped in some specific situations and there is hope
it might help in the future then I believe
[...]
> > > Overall I suspect there's one single case you're worried about, that really
> > > you want to put a WARN_ON_ONCE() against - then you can panic_on_warn and
> > > get what you want.
is exactly what you should do. But even then dump_stack should be
dropped to not duplicate the information printed etc.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2025-07-10 18:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-09 18:10 [PATCH] mm: implement "memory.oops_if_bad_pte=1" boot option Alexey Dobriyan
2025-07-09 22:37 ` Andrew Morton
2025-07-10 16:46 ` Alexey Dobriyan
2025-07-10 7:35 ` Vlastimil Babka
2025-07-10 16:47 ` Alexey Dobriyan
2025-07-10 16:16 ` Lorenzo Stoakes
2025-07-10 16:57 ` Alexey Dobriyan
2025-07-10 17:02 ` Lorenzo Stoakes
2025-07-10 18:29 ` Michal Hocko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aHAGeikybkJrPp6Y@tiehlicka \
--to=mhocko@suse.com \
--cc=Liam.Howlett@oracle.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).