[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a98b715d-011b-ce39-0872-2772fc619b7e@linux.com>
Date: Tue, 18 Jun 2024 09:57:07 -0700 (PDT)
From: "Christoph Lameter (Ampere)" <cl@...ux.com>
To: Chengming Zhou <chengming.zhou@...ux.dev>
cc: Vlastimil Babka <vbabka@...e.cz>, Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>, Feng Tang <feng.tang@...el.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
zhouchengming@...edance.com, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v3 1/3] slab: make check_object() more consistent
On Fri, 14 Jun 2024, Chengming Zhou wrote:
>> 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.
>
> This reminds me that we can't toggle slub_debug options for kmem_cache in runtime,
> I'm wondering is it useful to be able to enable/disable debug options in runtime?
> We can implement this feature by using per-slab debug options, so per-slab has
> independent execution path, in which some slabs with debug options enabled go
> the slow path, while others can still go fast path.
>
> No sure if it's useful in some cases? Maybe KFENCE is enough? Just my random thoughts.
The problem is that some of these options would change the total size of
the data stored in a slab. Features that do not require size changes can
be done at runtime on slab caches.
Powered by blists - more mailing lists