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 E7920C5B552 for ; Tue, 10 Jun 2025 13:23:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 812626B0089; Tue, 10 Jun 2025 09:23:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C15E6B008A; Tue, 10 Jun 2025 09:23:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FEF26B008C; Tue, 10 Jun 2025 09:23:57 -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 54B026B0089 for ; Tue, 10 Jun 2025 09:23:57 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F290F140327 for ; Tue, 10 Jun 2025 13:23:56 +0000 (UTC) X-FDA: 83539558872.15.E618B34 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf20.hostedemail.com (Postfix) with ESMTP id 2AD7F1C0005 for ; Tue, 10 Jun 2025 13:23:54 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=VT4EbDVT; spf=pass (imf20.hostedemail.com: domain of elver@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749561835; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vRaW1CqfHzqyG0OPt07OWDx5jYTvbBKbwah24QkbGI0=; b=E+I4KhTPqZPmNasfK69OddzVcLbXmDVPt3QeHV+Mnm1Q0l+oVQiMQy6lP7acNkTt+JyxzU Szgx0oVVXkNmQgO8k0xN0rVl5vo5bgGNzxMCzl6/kR01sSV6CQwi9ulYpF29oc0SuPkCsr rN+dE7qPs6qHBy3QGqiPSSEducsXT/k= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=VT4EbDVT; spf=pass (imf20.hostedemail.com: domain of elver@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749561835; a=rsa-sha256; cv=none; b=w7pRyZqbRZbjdznhiqGeQNOUKw/H00qDAzv/ze2M5jHoAHUCJRdO3s7oGGDF6zAIEYuY3m uFOBA0GDg1MYvzfdk/SfP4WCoz/RCPUwWBECT+3Dl++yGdvGW5IftuglCqDIBbdhkl6Q9V 2mUb/PHhQAlMpa+TEI9iXWw3pe4bANY= Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2352e3db62cso51190625ad.2 for ; Tue, 10 Jun 2025 06:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1749561834; x=1750166634; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vRaW1CqfHzqyG0OPt07OWDx5jYTvbBKbwah24QkbGI0=; b=VT4EbDVTy/lKIjN3mUElm3M9RtnQ2CKCWB9EtCYxGsIBvDpF5to40e6ubHrQndnDJ5 1XvIP09hZHiHY6Whem7R6z7bpy9ynEkYMqqZI103+WjgFnW3p2XKQZ769VTJXpPGrW8M NBjZR24A6iUxM5XlACycxCCqJnYabJ+s6sqrjR4ANW5ReMTw7Wnwt4p0ayUY5pNLuqgE doVSMOS+vdPCtp247kdkYBqWfOWtYBxGC/gu4X1bZHr7QyRhmQsIk4uMYrY1vTCWlsds B0OJEmYPzEViQFIKe3wjt3p4L3IkMjqUJfUoyzurUvrHOUKoFPdYz8aPtuBijobAAzba yRiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749561834; x=1750166634; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vRaW1CqfHzqyG0OPt07OWDx5jYTvbBKbwah24QkbGI0=; b=XKDl5yQpCBosdhpuZlNjBorUluEk9x4M7cZJN2i+fxfsHMhnUuOYGvua9/gkrcjMje fmgubv3OIotgY0J5X2EkYB4aRiH5kINl31ci7MK/6GI5b+sCOz3WleE0wIY8rgWSD68t MqCDoqbv4gmHEFh3hUWd7Ed+JpuPk2W/71DWoxWvZZLr6C9HlOyU13D2MpaW6pyhn9zo iS7iOwDLTzv5gv3CLSiGj71vw3USdLSEHigGGhsUfUqhqju4DQPjXF8pjfw5/Kp/AI98 ba9oZj0oSnWa0HZcu8sPUT38xeXd9pLXHgePcD2hHtA6juSaJF+6SdjTrByLl4sGBb/K ZCWA== X-Forwarded-Encrypted: i=1; AJvYcCV77YaKcSYCAPBDCuxQvojaJKUAra3UzwOzdYTmYpN/3RkuoqjUEyOPWK/kKI0ZyTpPHRCzwUmQOA==@kvack.org X-Gm-Message-State: AOJu0YzyBYvibyAxbyVeJzA3Y/7cgNOrS+EQRjCQYZYYA4x6S60TGUQw HhTjEtG5U7XNJY1vt+pDQMJqMdBSOxES3dyE6LHUCV6ucI3lzanQrYAi4PZIsiCNLRwEoryhxPq U55lGzm7VZ7yFx3bJSNs373MPe3UMvQJFpOJQ/eDJ X-Gm-Gg: ASbGncs90PNcmRv69mKfcQ4p+uHwhxXFt6jkLEUiXnBid0Rv+ZtthM2vlPr9Gx6WwwM 1FiGC0cfoZZzuuNIq91ATjU5HlY1/d2hcq1jYacSMWhBy7N4I1Ie6eJrEd2z+MQfvx595j1Bfto DXE8pVKoxh3041GYqtVpIG5GHnnXj1sWIR7ncg8g4VapqRE2uKo4GLH88Xk+4RQrpDamcTYmm9 X-Google-Smtp-Source: AGHT+IG7PY0D0ArhlOb4GkHNu8Vx5hAhL0JBejCfN4iUUjwc5TYU5Nw17Azb58ct6u0hY7RY33pCL6bjhMnZZXNWaBM= X-Received: by 2002:a17:902:e888:b0:234:8a4a:ada5 with SMTP id d9443c01a7336-23638390915mr37412415ad.37.1749561833582; Tue, 10 Jun 2025 06:23:53 -0700 (PDT) MIME-Version: 1.0 References: <20250606222214.1395799-1-willy@infradead.org> <20250606222214.1395799-9-willy@infradead.org> In-Reply-To: From: Marco Elver Date: Tue, 10 Jun 2025 15:23:17 +0200 X-Gm-Features: AX0GCFtTJcTed3U6440yYHTEXfipib5aKPmkHTxU6Gll8_BS05WLR7SDouZ-yfU Message-ID: Subject: Re: [PATCH 08/10] kfence: Remove mention of PG_slab To: Matthew Wilcox Cc: Vlastimil Babka , Christoph Lameter , David Rientjes , linux-mm@kvack.org, Harry Yoo , kasan-dev , Alexander Potapenko , Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2AD7F1C0005 X-Stat-Signature: sadtssdwg8qwezw8x7jf1tztfxit5w6q X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1749561834-78922 X-HE-Meta: U2FsdGVkX196pLRU8TMdiM5hbUlgYaSdK+DS0adu1eQBJaVHpKlchC6IdQTW2ovr4efAm+JHLNDxRWs4ejPT2TYl/pHotOEt9KRXMRKe0CHO8hp67LBAu6Xyf/VTIKqRmZRWmghJ87Lwbq2yev88sv+SJMhgt7teNHnrW4eoJ0S0BxA3MEKRi9/Xy9ulCfEIVNXTvX303ureiGGEsDUhajQZNvTNuNIwA9JxAPQhjBwK05fUf1wxG13BhBlrGsfYqvd91Zdv0stL+b9WNrau7Q5xZcrfVmra0cn2TXFUWmgfP+qE+m2jjvpCK5O/+Ame25tUP/ejSSjMg3fuawVUjGNh9BIqKZvftvRf3oXplFki8vqFyioi1ARUqofNYizGaMf0q3syzzvXgQ+DvBKJDebRsHdaajU7t0UfybzKzaRncebgEONtyV0DRPLE6/OhyrPhsXcQJtPWAeAL3nWkUl6AB0PpQgatOCSqe/2GjnBfPtLYyt+LPBx+iI8wtwKsnlMCXRWpdz/JSHix8SBFjzr5X9k3RnAJA49ou08SlzL5Pk4Lyd3W7nhOQyYsOiQlrrAh0wq0b2JT1dFzlSOyNIvNZEI9hRbLmg4NsFltdMLATkpnUwc5JNhamsTsiwz+ClbrJdurGEUW3wp99ktH+dpGvDbRXHuW+TI2xgN2J0mFQmZoMlwKu0GtDf0ctqdO/9+nVgcQQxyptafHBbjBT0EIsbk4SuEcy/azSw2Z/f+K94yxKbfY9KyGURq9TYclqL7FYyJqPeD47KStRU4ETE3HcCzR2yEz4vVNqgeIt1WmO7DhV0Y3qpTCZJF5whlow0p/T5b8PB2jk/tBZRncksOhcG6dgSD6ulWvPoH7XfEwBhOebSF+Vu6HlyZ+RkZMdM44kPmDpFrcVLfMOvOVnJmy/P15TT311tHyUjThrL4TyQBQGhIaazYMXRmkeh/iqURcGAHfWYzgEc2gVrd A1hR2HYr ncAiqZGxZlsKBM7YISqFIia0Ba7BqmcQWZ8JW+97fdhgSlWBNed43aRFxK1C8homixj1ysi3JFfvx34u7uQscPf/u+vTYPYjwB5k/4QEcGX9drLEQRFZ253xQfPgHfuNk0Wuw2fse8ynTXaAkDjXhCyrucwvd56z7GW3RMh3MIv990s3HRVn58PRqXRgaQPiZ2DSUaTLGsi3eMCUF2BqOnwUmwY2bhWShMFGpVYYXjsczSIUjcFiYfhLjzdSJXEb1jM1aL8H8rAw7lBhPYr26f6/k9gvPmhIbJk7PCR+RqGrKL6tO9RvrjFOPIY3abgIQY0PM 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 Mon, 9 Jun 2025 at 17:02, Matthew Wilcox wrote: > > On Mon, Jun 09, 2025 at 03:33:41PM +0200, Vlastimil Babka wrote: > > On 6/7/25 00:22, Matthew Wilcox (Oracle) wrote: > > > Improve the documentation slightly, assuming I understood it correctly. > > > > Assuming I understood it correctly, this is going to be fun part of > > splitting struct slab from struct page. It gets __kfence_pool from memblock > > allocator and then makes the corresponding struct pages look like slab > > pages. Maybe it will be possible to simplify things so it won't have to > > allocate struct slab for each page... > > I've been looking at this and I'm not sure I understand it correctly > either. Perhaps the kfence people can weigh in. It seems like the > kfence pages are being marked as slab pages, but not being assigned to > any particular slab cache? They are marked as slab pages, because in kfree() there's the test for folio_test_slab(..), which goes to free_large_kmalloc() if it's not a slab page. But the kfence pool pages cannot be deallocated, given we want to reuse them due to the particular layout of the pool (object pages interleaved with guard pages, freed pages are only marked not present to catch use-after-free). But besides that they aren't real slab caches, given it's all managed by kfence (each page can host at most 1 object, but those objects may be of sizes up to PAGE_SIZE). Some of this could be solved by adding more is_kfence_address() checks, but that adds more branches in hot paths and more complexity since some of the accounting and hooks are naturally shared with the current design. > Perhaps the right thing to do will be to allocate slabs for kfence > objects. Or kfence objects get their own memdesc type. It's hard to > say at this point. My plan was to disable kfence (along with almost > everything else) when CONFIG_PAGE_DIET is enabled, and then someone > who understands what's going on can come in and do the necessary to > re-enable it. Assuming it's not a new default, and if this new feature disables most slab debugging anyway, this appears reasonable. > > > Signed-off-by: Matthew Wilcox (Oracle) > > > --- > > > mm/kfence/core.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > > > index 102048821c22..0ed3be100963 100644 > > > --- a/mm/kfence/core.c > > > +++ b/mm/kfence/core.c > > > @@ -605,8 +605,8 @@ static unsigned long kfence_init_pool(void) > > > pages = virt_to_page(__kfence_pool); > > > > > > /* > > > - * Set up object pages: they must have PG_slab set, to avoid freeing > > > - * these as real pages. > > > + * Set up object pages: they must have PGTY_slab set to avoid freeing > > > + * them as real pages. Acked-by: Marco Elver