Received-SPF: pass (google.com: domain of linux-kernel+bounces-214242-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <e655405f-92b2-46e4-830e-013586bd0022@linux.dev>
Date: Fri, 14 Jun 2024 10:40:30 +0800
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PATCH v3 1/3] slab: make check_object() more consistent
Content-Language: en-US
To: "Christoph Lameter (Ampere)" <cl@linux.com>,
 Vlastimil Babka <vbabka@suse.cz>
Cc: 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>
References: <20240607-b4-slab-debug-v3-0-bb2a326c4ceb@linux.dev>
 <20240607-b4-slab-debug-v3-1-bb2a326c4ceb@linux.dev>
 <63da08b7-7aa3-3fad-55e6-9fc3928a49de@gentwo.org>
 <8b844d71-01f1-472b-a63a-4c9cdb26e9ef@suse.cz>
 <e93fc5a6-434f-376c-a819-353124da053d@linux.com>
From: Chengming Zhou <chengming.zhou@linux.dev>
In-Reply-To: <e93fc5a6-434f-376c-a819-353124da053d@linux.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 2024/6/12 06:52, Christoph Lameter (Ampere) wrote:
> 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.

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.

Thanks.