From: "Christoph Lameter (Ampere)" <cl@linux.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Chengming Zhou <chengming.zhou@linux.dev>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Feng Tang <feng.tang@intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
zhouchengming@bytedance.com, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v3 1/3] slab: make check_object() more consistent
Date: Tue, 11 Jun 2024 15:52:49 -0700 (PDT) [thread overview]
Message-ID: <e93fc5a6-434f-376c-a819-353124da053d@linux.com> (raw)
In-Reply-To: <8b844d71-01f1-472b-a63a-4c9cdb26e9ef@suse.cz>
On Mon, 10 Jun 2024, Vlastimil Babka wrote:
> Even if some security people enable parts of slub debugging for security
> people it is my impression they would rather panic/reboot or have memory
> leaked than trying to salvage the slab page? (CC Kees)
In the past these resilience features have been used to allow the
continued operation of a broken kernel.
So first the Kernel crashed with some obscure oops in the allocator due
to metadata corruption.
One can then put a slub_debug option on the kernel command line which will
result in detailed error reports on what caused the corruption. It will
also activate resilience measures that will often allow the continued
operation until a fix becomes available.
next prev parent reply other threads:[~2024-06-11 22:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 8:40 [PATCH v3 0/3] slab: fix and cleanup of slub_debug Chengming Zhou
2024-06-07 8:40 ` [PATCH v3 1/3] slab: make check_object() more consistent Chengming Zhou
2024-06-07 8:58 ` Vlastimil Babka
2024-06-10 17:07 ` Christoph Lameter (Ampere)
2024-06-10 20:54 ` Vlastimil Babka
2024-06-10 21:37 ` Kees Cook
2024-06-11 22:52 ` Christoph Lameter (Ampere) [this message]
2024-06-12 18:39 ` Kees Cook
2024-06-14 2:40 ` Chengming Zhou
2024-06-17 9:51 ` Vlastimil Babka
2024-06-17 10:29 ` Chengming Zhou
2024-06-17 11:08 ` Vlastimil Babka
2024-06-18 16:57 ` Christoph Lameter (Ampere)
2024-06-07 8:40 ` [PATCH v3 2/3] slab: don't put freepointer outside of object if only orig_size Chengming Zhou
2024-06-07 8:40 ` [PATCH v3 3/3] slab: delete useless RED_INACTIVE and RED_ACTIVE Chengming Zhou
2024-06-07 9:27 ` [PATCH v3 0/3] slab: fix and cleanup of slub_debug Vlastimil Babka
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=e93fc5a6-434f-376c-a819-353124da053d@linux.com \
--to=cl@linux.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=feng.tang@intel.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
--cc=zhouchengming@bytedance.com \
/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
Powered by JetHome