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 5371EC3ABDD for ; Tue, 20 May 2025 14:18:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E61CF6B0099; Tue, 20 May 2025 10:18:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEB006B009A; Tue, 20 May 2025 10:18:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDAAC6B009B; Tue, 20 May 2025 10:18:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A9B666B0099 for ; Tue, 20 May 2025 10:18:46 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 516401A0480 for ; Tue, 20 May 2025 14:18:46 +0000 (UTC) X-FDA: 83463492252.10.7BE0C96 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) by imf22.hostedemail.com (Postfix) with ESMTP id 6BEA3C0008 for ; Tue, 20 May 2025 14:18:44 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cp5y5e6S; spf=pass (imf22.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747750724; a=rsa-sha256; cv=none; b=iF4658Y0UwLwizHXpTeDDyoheMMo7mrd4iOJrY/jmnyJsbdeTuUXZ0fRFAc9IfUBUM7q4m XmKsNdMxKqpXMvNSKCNv+Q1/K1kjcyDwaKkCg7fZXs/mj9l/dn9VNta6zz3hqvpCO0AvX2 5qJVGtQhW5ByMRfSsI79UQ3MIdNhBBk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cp5y5e6S; spf=pass (imf22.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=shakeel.butt@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=1747750724; 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=rFwCIYRzvivPUpYkVHoooHboU3UiLo3gQHBSoPT9tl8=; b=Cug861VOhfAb6W9fVZwrCLEMAuqg/7tIxm7yEKYwh3Eh8TZBhHauVl40v1NCRv4YuV2Md9 387GJ5iFiUBdTfP6Z1g6aYJpv6EcbPp3E9fdEZDp8efY7WhJ9dD/v15x7+hKdhky65tXGQ H+gwUmLqDSP9CufFCPldXxU9axyRFlo= Date: Tue, 20 May 2025 07:18:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747750722; 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: in-reply-to:in-reply-to:references:references; bh=rFwCIYRzvivPUpYkVHoooHboU3UiLo3gQHBSoPT9tl8=; b=cp5y5e6SU4YVtdcAtwm9kMPfUTAjrY5+zYTk+C/qEjtajECvAv/W7ALjkTregnupGrmpwR CYQM/GgUFquJ08kIWlg2Dn3D4pN/ojNcx6LBw8SX90QgIDtEOoGPBuRDrZjwd99Dv1yQ13 apYyXvUAbQ3aEPd0sw/VG2OTaSm0lGo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Usama Arif Cc: Harry Yoo , Andrew Morton , surenb@google.com, hannes@cmpxchg.org, vlad.wing@gmail.com, linux-mm@kvack.org, kent.overstreet@linux.dev, linux-kernel@vger.kernel.org, kernel-team@meta.com, vbabka@suse.cz, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev Subject: Re: [PATCH 2/2] mm: slub: only warn once when allocating slab obj extensions fails Message-ID: References: <20250520122547.1317050-1-usamaarif642@gmail.com> <20250520122547.1317050-2-usamaarif642@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6BEA3C0008 X-Stat-Signature: su514oqtewey8pen8yayhes6pqriexqg X-HE-Tag: 1747750724-886140 X-HE-Meta: U2FsdGVkX18qY9aKR6rp9DsUdGrBqqnkxqK328Pl0Nhj/aLEgG/4WkuFjzZIXFrh0oIByXL+1DT7UtuaJaZ1pfDhwgYQhUs3C56j1cDyTwUVlHb5NxfbVaaZ6ja3aVUbko7tZRbJNDQ0jJTDwqo/zegzITksEiaYo7WNrzu2K4qZx6bOCkTOTWPRpcDmMYhhX2dXOQX7aX4i5K4v7FtjPgH73YD5JP1cD05mS71+cR64U2s+PRLEuflE2LNB9XT19ReMiDqPLzEolz/VM4InycKtAugFa5tcSa6aoBm7wYhB6hx7vsYPmNg68+Z/c1ilqhxbjeZ7ZLdTs+ZE2AUWqd5husuDz2PlhUkh7uRv1iKlPq8uZ5mckC1F+AZ/Pt/m9iDlKHOmdXS1OQh5Pc1Rd8otXn4p7Oj6Xuql/Y6eGZaOsHSFW75hxiZ8kGa25dLFJO6t0Vpb4nuOvNoFu9e5kZQp1IIeQDxVxFmaaL+DqD/04PHqSWwqMIpkn6Y7mz7XO+S+9rey+hugDvt4EOpKRMRf8e+5z/23/nxNSlFWyk4Lrha/HvI675/OSYMmjyKuHnDCy/M1wrByToZm/zoy1OJn0YAnD1eQKgqJhO+v5/Qovf4zaumJxEpzRpCWrfcK+ynMvDBSaQPXsvKdkTl52MolRqeTJKjApMb/Qr0//BlUx2BhhkObjn08FReXCHP4pm1+LVXKA4YwjOj5TwyfXTPQYNdAXEsefUDqOpDM/GI+vkxtVcsMSlD6jj5aKSa0B6hMzLtLmyBHjucGm8e/OoS+zGfLn4HLlPC++goFUiqrSFTJOxoxgpkGYs65Os923dJHLuGwuuhxMG/QOIi+xlOYBZrVbyzbv2fUiVrKisEwMR8EAV9zc2fVFWSd2dP9stNJ/J+wXESHYOyF79HoF2DXoKzOkXPVQVPs4OOhI+RbSpHqqrWfgwXIqTwqq0tDkZq7sZQEhKF00/9s954 UU3UVM5x ZClXhLYQwxsgDm1E8JpU8cYQMMSPC//6SE7ji6XymI9656rNgk29gEGUUEQd37g/N9abKrvVIt+hAbI0/lMxy8E+FLW0pU5BG7LLP19xSvJqgtKFRu0IvPYU17vsPF9P0s1kxF0Piwpx6ANlnBKuBufeI4waounPBywYOGm2c2wGO5YeHTFSTRVyPZ/6IpuDjKfvud9oKu3VlsB2Fr6/xHctZon0zY0gxxf8ZcEInLYq8r2kmxmxG0Nj9VZNAlqLcCJ6AvCD7kaY7O/LQexFLZABjk4zc1QOOBxRpnCgooDLl0bkxq8hRLe9vjOKFgODysoEt+3eO4EJD4qo= 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 Tue, May 20, 2025 at 02:42:09PM +0100, Usama Arif wrote: > > > On 20/05/2025 14:34, Harry Yoo wrote: > > On Tue, May 20, 2025 at 01:25:47PM +0100, Usama Arif wrote: > >> In memory bound systems, a large number of warnings for failing this > >> allocation repeatedly may mask any real issues in the system > >> during memory pressure being reported in dmesg. Change this to > >> WARN_ONCE. > >> > >> Signed-off-by: Usama Arif > >> Reported-by: Vlad Poenaru > >> Closes: https://lore.kernel.org/all/17fab2d6-5a74-4573-bcc3-b75951508f0a@gmail.com/ > >> --- > > > > Hi, > > > > Please Cc SLAB ALLOCATOR folks in MAINTAINERS on patches that touch > > slab code ;) > > > > Thanks for adding them to CC! I was just thinking of this as a memory > allocation profiling issue and added the maintainers for it, > but should have added slab maintainers as well. > > > >> mm/slub.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/mm/slub.c b/mm/slub.c > >> index bf43c403ead2..97cb3d9e8d00 100644 > >> --- a/mm/slub.c > >> +++ b/mm/slub.c > >> @@ -2102,7 +2102,7 @@ prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p) > >> > >> slab = virt_to_slab(p); > >> if (!slab_obj_exts(slab) && > >> - WARN(alloc_slab_obj_exts(slab, s, flags, false), > >> + WARN_ONCE(alloc_slab_obj_exts(slab, s, flags, false), > >> "%s, %s: Failed to create slab extension vector!\n", > >> __func__, s->name)) > > > > I think this should be pr_warn_once()? > > I'm not sure why this was WARN() in the first place. > > > > Isn't WARN_ONCE the same as pr_warn_once but with needing the condition > of the first arg to be true? We only want to warn if alloc_slab_obj_exts > returns non-zero. So WARN_ONCE should be ok? > The difference is the impact on panic_on_warn users which are mostly testing bots. This warning is not actionable, so I agree with Harry to covert this to pr_warn_once(). > > The coding style guide explicitly states that: > >> Do not WARN lightly > >> =================== > >> > >> WARN*() is intended for unexpected, this-should-never-happen situations. > >> WARN*() macros are not to be used for anything that is expected to happen > >> during normal operation. These are not pre- or post-condition asserts, > >> for example. Again: WARN*() must not be used for a condition that is > >> expected to trigger easily, for example, by user space actions. > >> pr_warn_once() is a possible alternative, if you need to notify the user > >> of a problem. > > > > And failing to allocate the extension vector can happen during normal > > operations. > > > > panic_on_warn users will be unhappy if they notice their kernel panicked > > just because their kernel failed to allocate slab extension vectors, which is > > a totally normal situtation. > > > >> return NULL; > >> -- > >> 2.47.1 > >> > >> > > >