From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04429C27C79 for ; Mon, 17 Jun 2024 10:29:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 753656B016D; Mon, 17 Jun 2024 06:29:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B4756B016E; Mon, 17 Jun 2024 06:29:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5066A6B016F; Mon, 17 Jun 2024 06:29:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 28E986B016D for ; Mon, 17 Jun 2024 06:29:23 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BFE70121539 for ; Mon, 17 Jun 2024 10:29:22 +0000 (UTC) X-FDA: 82240008564.17.D8CB5B4 Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) by imf03.hostedemail.com (Postfix) with ESMTP id 84B0B20010 for ; Mon, 17 Jun 2024 10:29:18 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ioKneBWz; spf=pass (imf03.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718620156; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sMMkLXHJEJk5ByM0Fas8t3kBq83vm0c2mSUgof1iK64=; b=RqyDO7qB/xRhf/QVi8Yv+flLD5oSsneNEKAUB/H10+AGHeOqz5t9tx81kfCvmBTW021auI YwQxo7TiAg3a7PksqEk1gzT1muDwU8j7pyN8dPuTt3euJaf7+W6PpiPal5pyKU9fjLu7qp qaoX3JkyKo8mgy9oNjjhobmFuNuJjAY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ioKneBWz; spf=pass (imf03.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718620156; a=rsa-sha256; cv=none; b=46vCWHxCVzhNSfYVBYVNRMI4Ddg2oQ5apn1wYMpYLsH8mCEWgDgPmcGtoteWYSIhLXW8We e8CnqkRK1OaxmndMMFqkH2SQ76HjL9dJcoRSjFzIjMaiVKQ0pTYmSzsw0bzNZ0oKdy4yk8 bM8hMIL2Lc5/vvHCZUKNAdZgI9wJYmI= X-Envelope-To: vbabka@suse.cz DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1718620156; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sMMkLXHJEJk5ByM0Fas8t3kBq83vm0c2mSUgof1iK64=; b=ioKneBWzylxwpk627whO+6QXjE/SbQubI1siMnUW4JkarSj0eqGHvbfZv2yNT6yC/5oHCl 39e3TGkZvKonEld+Wv8+oSt750ULINO0OoLGNwiktA6Bqt8fRwJJqdwDTOxM9AKr/M49wk FOcbTDh2yTgKyZMT9lCEftT2PCyny+A= X-Envelope-To: cl@linux.com X-Envelope-To: penberg@kernel.org X-Envelope-To: rientjes@google.com X-Envelope-To: iamjoonsoo.kim@lge.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: roman.gushchin@linux.dev X-Envelope-To: 42.hyeyoo@gmail.com X-Envelope-To: feng.tang@intel.com X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: zhouchengming@bytedance.com X-Envelope-To: keescook@chromium.org Message-ID: <0c0e0892-8410-4a7a-9f12-23b9cc2ef544@linux.dev> Date: Mon, 17 Jun 2024 18:29:07 +0800 MIME-Version: 1.0 Subject: Re: [PATCH v3 1/3] slab: make check_object() more consistent Content-Language: en-US To: Vlastimil Babka , "Christoph Lameter (Ampere)" Cc: Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Feng Tang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, zhouchengming@bytedance.com, Kees Cook 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> <7eaee8ce-ad5b-41ea-9eb5-83195f83fd24@suse.cz> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <7eaee8ce-ad5b-41ea-9eb5-83195f83fd24@suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 84B0B20010 X-Stat-Signature: 4ni9f8nhjhn437x97tgqhd3tbi544y54 X-Rspam-User: X-HE-Tag: 1718620158-90405 X-HE-Meta: U2FsdGVkX19p4LB8qe1Q+TTrNa6W8Hz4s8ZABX7qxWNFC+yFMZIqzDUrMijFNjHH/m/xc+ldC9++zp3Le2UQvVVaQAc8CfDccp0TSt72gE4LFaj9wYr5jG/npzN6vmVT0qq93ziprWduy1AhwJ1R/9Mw5GkoY1CGb+HtVCFF5GZ69cgBt7wQid1Ohg/vW+GRqnH+NniTOPwyPMR3LD/mbNIc+/Inq+OQ+1R6O8cAiMAG/jT013G/pcbEb0KRmoduLChCs0ODUYY0NmqfDQuTTt1nSRSJhHG0TQRiXG4/mhtRuoXpB9kJkY22K7B/kzmfpWCOOb8KLgU1Ft4CVeHatMEzbt1gfuRFG4Ej1sgJxq+R6ysr60ymxirvIFZcuM3zE0KFQ/+bL5ltVz59vJbkGya1P6yRCWCtT5I2L1JN6ZVZccjMdvsMYPIbIKOjnAqWynMcIRME3ZPenNSu1BF//C+5r0YZTxWi4gdpiKn2E92TVwfiWrSRcFIdvZRd8YO/ezKMIzhvOq3dh3C9aly+y03Qg6DwIjSD3eUg+VZZ1sHtMVczBQSZgS4X3Rggmm2O7ee96K7CiBvW1cQ+4YfjhBeYVEyz7AmHtXHMAb7rs+cPsWZACU5wc5kxad+eEIwehnYhO5bjD6NqFVwQoPegJIggwH6dSvGhoBR64kGXwPRqexcTSjIPWgAW/nc64yVLZyRqmsG7GQDRBdGDCtj4QNfa406jnyUGNT0DxZE/b/6ikf9xu3zTOVRsInzK8OR3rUC2pBSVIXfDjX9ks6Qg4T+V8DNAjRfUO+iEBwkomx4MpyWMbW1NrH0azpILwM2AqR2RmMf6S62AEWHnUv8xo3QYP356+gTkyG6jyMwZV/xmIRjMG4XvezJUIR32P0UbrqpoIVgJfT5NEOghy4+bfqra3XpwmpjPwZyg1npKWxINKAClahJNXx0lUf7Y7rgabPfcFLn7Nph3JTl3Ocq DYraSPnW p55Drd7YKBR+f1ONMapUr57qOcN+WGKiTnoIqS5UZITZtLwiYal84qimRgu6kXVPO8tDkC//HMFhQDzYEoqbWdkFVmj+DlDLGKql1grBWf3WGqKvvBzvanZxYa0eYxRRHKVm+u/f3BcmN29OcA4rd551bzi6Ze21n9B3J8XlzlnqctFU7ehGNGe6cTTKnnbiz+1ZeXn+daubsXCq4pumMY2CnEYJUoMhtBlMBfJBTOVNTONA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/6/17 17:51, Vlastimil Babka wrote: > On 6/14/24 4:40 AM, Chengming Zhou wrote: >> 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. > > Many of the debug options change the layout of objects in slabs (i.e. affect > calculate_sizes()) so it would be very complicated to change things in Yeah, so each slab in the same kmem_cache can have different layout (caused by different debug_options enabled), we use these different information to decide which path each slab should go. Then the problem is saving these different layout information for each slab, which has an unused _mapcount to reuse, can be used as index to find its layout information in the kmem_cache. I haven't thought too much about this, so must be missing something. Thanks. > runtime. Also the cache might be merged with other ones if it boots without > debug... I don't think it would be feasible at all. > >> No sure if it's useful in some cases? Maybe KFENCE is enough? Just my random thoughts. >> >> Thanks. >