From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f54.google.com (mail-yx1-f54.google.com [74.125.224.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE6382D73B8 for ; Tue, 25 Nov 2025 18:44:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764096261; cv=none; b=IQ3OkhZ+6WjoAd6zk3CnMkNY3e3kZv62q/r5u5FdPzyNJq78yGgtgHr6c+aaXtm2VlMy//kIC8saEw4OJNB7u1a8DwpgPGT/ZNz3MF+H/AVH0nfehm7x00p3gy7RVV9K6OtDZpD/+bQ/lSJz+uVnOcGkkrNUJUXMUZBlBzAxpYk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764096261; c=relaxed/simple; bh=h41rvwq00iAAMBX9jSxM9Flk4uh7o21WQ52nLsax6Y0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ACTOCQj8PCc0nisGLH3iOqkjzV328KezaUE11sehXY2DscAxqiqaGpWQK362GX064rBT81XyCDw9/uYT0Io14H1jz3t3ERTGb7cRZ7/MlI4mPNNUkeHhka2Q4rNCJnbpqNPJG6d4A4qIbNu3SEIzGCA3Kwq3i0bLriHZH9uB/Tg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=V6kmdJly; arc=none smtp.client-ip=74.125.224.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="V6kmdJly" Received: by mail-yx1-f54.google.com with SMTP id 956f58d0204a3-642fcb38f35so4217943d50.1 for ; Tue, 25 Nov 2025 10:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764096259; x=1764701059; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EuCC5DFWaWyOL4X15A+FY0iDuG43APf6t+DuwQP4zFQ=; b=V6kmdJlyF1SaFhR0v7TrmHDbXrpefM/gZiMsrzP/yECoIBMzZuEjPUh9eOcVdxqDHg aCUG2Be1O1+boMdaY9eMjRGVxfx2Dl5FUSZwSRBGvQ4Q3so4tahKJOqUrwNWPNly2mXo eQa7Ynxi5Ewi5lxrq9DKRg/YxSJWRV9no0me3ookLfmGACZ6bsNZAHV8hNnFyPkYv+dv HH0TU2kq5qGem5/+jiKFfZIYnHe+pVPUVPIOSwDod6jpcKP3WnltSmAf9f+5jTwjVuwQ niQ7DkXdDq/F/N5kQUbtW13DTQfD5T8mTj0Ndsq37vn2lcnSUU08/8luX8mtpuw2KlSF Wa3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764096259; x=1764701059; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=EuCC5DFWaWyOL4X15A+FY0iDuG43APf6t+DuwQP4zFQ=; b=E14TZpyvgbfGJSTEtZupBKqGQofdfEsc7Ul6H0HeRrC3i2ZsvuLzZJxXaQsCsfhuaT tE2Cl0RoyH6vk05hHpxJ0lP3itYC09XEPWeqRt88HTBtyk24HjYFK8gnuQ7oboNbP151 wscdCm4GLUnzoqaw59MMu1+kT79H0BAxos2Uj40tzvlwqraHMrQ53vcEtVjVoR7UBITg 510/MHn01+y628AyXKmXWoWj4qIrpuNUcItVRGmgnfF/a6eVAbGTjSHJpk27pT08CD+B kuKvtVLZI8+9QF8ygw63PU/hvUruRq10m7b98Tw9uPPj6TT91fO5IEVzcnDW9c/+Zojk 3srg== X-Forwarded-Encrypted: i=1; AJvYcCWodUPR5xkOsVSI6e7T4BTTCJsLiFO6sn84xp+Xz98vGxXamdSmW5nk8Nmd3Mb09pgO+a2oQg8qQ3O6JZA=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/t5gGopevZW1bteZmDRKYciiXvnkrfdH0eoU9p44/+hGqazHk 39g8HZHzyaBlWHRwBcZU0z7OHt6F+oXiL6icmNpVoYDyYEUQnUwTexrS X-Gm-Gg: ASbGncvEUcjMi6RKgDZf8/YYWREQ7Bf0YfpHFsM2OPV/3amKs+GSDm2PvtvMdHQEa0W PSO2ynSi6cQPiQ2gwOjaXqqGgJ9n0JaSpJXDvEQXpuMd1NL5sEtqKDyfmecMsIbHSaVZb51ynpq EIHYcgDiw8R3KIBGcwxvIHZE8AqO3CW40uAtIEN6g4/h03wWWPPZu05KZza3FWFnkm18C723JyT sprxuHSIH43Prps44nE2Q/prA2/OtJix4+Z+RcCf+jzvfro58v05MAwG7enV8v1IxKX5kabQraZ bOSoVaVRFm9f9ODnV/wEcZuHxktzUC+PC4j/YeJebs+2yixdYbpZ3P3jgw8e5aZB302FdIdhKFc mHpLDd7D1AhBdELl6HXjKFZgseoeSRvCOPeYhWuG600eKTA1ypFVg/fubEgBIutuxoJNSoOH09R ZthrURf+1wLDveWCNIrcoyZw== X-Google-Smtp-Source: AGHT+IGL0IWhgJSuT0/x34hD1ZnZBCQoO9+9MuB14e3zIBSvN6lwZFY8kFf7BpE4AVJ8D7mB99nxjA== X-Received: by 2002:a05:690c:4a11:b0:786:59d3:49c8 with SMTP id 00721157ae682-78a8b54d8b4mr132611937b3.49.1764096258560; Tue, 25 Nov 2025 10:44:18 -0800 (PST) Received: from localhost ([2a03:2880:25ff:13::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78a7992511esm58735867b3.35.2025.11.25.10.44.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Nov 2025 10:44:18 -0800 (PST) From: Joshua Hahn To: Mike Rapoport Cc: Andrew Morton , Vlastimil Babka , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com Subject: Re: [PATCH v2 1/2] mm/mm_init: Introduce a boot parameter for check_pages Date: Tue, 25 Nov 2025 10:44:15 -0800 Message-ID: <20251125184416.1493908-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 25 Nov 2025 12:23:14 +0200 Mike Rapoport wrote: > On Mon, Nov 24, 2025 at 02:54:06PM -0800, Joshua Hahn wrote: > > Use-after-free and double-free bugs can be very difficult to track down. > > The kernel is good at tracking these and preventing bad pages from being > > used/created through simple checks gated behind "check_pages_enabled". > > > > Currently, the only ways to enable this flag is by building with > > CONFIG_DEBUG_VM, or as a side effect of other checks such as > > init_on_{alloc, free}, page_poisoning, or debug_pagealloc among others. > > These solutions are powerful, but may often be too coarse in balancing > > the performance vs. safety that a user may want, particularly in > > latency-sensitive production environments. > > > > Introduce a new boot parameter "check_pages", which enables page checking > > with no other side effects. It takes kstrbool-able inputs as an argument > > (i.e. 0/1, true/false, on/off, ...). This patch is backwards-compatible; > > setting CONFIG_DEBUG_VM still enables page checking. > > > > Signed-off-by: Joshua Hahn ... Hello Mike, thank you for your review! > > +static bool _check_pages_enabled_early __initdata; > > No need in the leading underscore. Gotcha, no preference here on my end at all, so I'm happy to drop the leading underscore. I was just modeling the variable after _init_on_alloc_enabled_early and _init_on_free_enabled_early, but it seems like those are the only ones that do have this leading underscore anyways. > > + > > +static int __init early_check_pages(char *buf) > > +{ > > + return kstrtobool(buf, &_check_pages_enabled_early); > > +} > > +early_param("check_pages", early_check_pages); > > + > > /* > > * Enable static keys related to various memory debugging and hardening options. > > * Some override others, and depend on early params that are evaluated in the > > @@ -2591,7 +2599,8 @@ static void __init mem_debugging_and_hardening_init(void) > > * of struct pages being allocated or freed. With CONFIG_DEBUG_VM it's > > * enabled already. > > */ > > - if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) > > + if (!IS_ENABLED(CONFIG_DEBUG_VM) && (_check_pages_enabled_early || > > + want_check_pages)) > > You can initialize want_check_pages to check_pages_enabled_early, would be > clearer IMO. Yup, totally makes sense as well. I'll include this change in v3. Thank you for all your feedback, I hope you have a great day! Joshua