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 7FB0DC3ABDD for ; Tue, 20 May 2025 15:14:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 184AF6B009A; Tue, 20 May 2025 11:14:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 135C26B009C; Tue, 20 May 2025 11:14:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04B336B009D; Tue, 20 May 2025 11:14:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D8C4A6B009A for ; Tue, 20 May 2025 11:14:49 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8075CBA5AB for ; Tue, 20 May 2025 15:14:49 +0000 (UTC) X-FDA: 83463633498.05.A0851BE Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf25.hostedemail.com (Postfix) with ESMTP id 94258A0005 for ; Tue, 20 May 2025 15:14:47 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=V9CANQhH; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747754087; 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=iSrpfL8xaFpRULZ/wjVaUfdkfzWgu438uQCRPW9kiS8=; b=bFwMyJP5o9wTT9f/YMwXDW4kBBZnbkIYDjt2WB8sLWGSbVwWpHABh4myfl4IgDna5Ju5mz 6G3rbfsBB9utRdX3aXMOKEnWmGfrzH2eWCEZJBFQLcOStBvPmhBBTy+iwAqz14d2LdyzMQ FUkniMXg3QDo/fthTi2tLmoIJ3Zs57o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747754087; a=rsa-sha256; cv=none; b=MgwCt+aqcwo1sjQj1qjKFfrHsN+eGPw2PvzCnBq4f40/wlMuKX0SiDRv72WHLQKU3a0Z81 ukrQjqQ/9IkyHsbCpddOA6/ASKvHcn8bLXsFGQYdrxNiLyVd0Jjjih6c5xaqLnub3KHYQG 0G7/OQEYKdiLuImZ/S65mEki6UZqkGQ= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=V9CANQhH; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4774611d40bso857001cf.0 for ; Tue, 20 May 2025 08:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747754087; x=1748358887; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iSrpfL8xaFpRULZ/wjVaUfdkfzWgu438uQCRPW9kiS8=; b=V9CANQhHw+6onsFSdkcbgy5QQDnrr5nUew155fNHgkO11LzUPiYFdz/kSatjpfiaC4 3O3NkXbLVZUPj6N3HpxseTQZncbDwM8E08iSGvHEpCgxTGGaClPawJ4RUGBgnliXM8KC zJdkx+TmNCiFgRHjuAz8p4T71JEG6EXcpxWECWZ0mgjZs8uOIwKIsHpI1UWlvy8ALtPH VTkRv0oMUFymBGxT/Y5Z07r1aqfb/mhxdeoJh1Y3Tnlv4YIoO/rpAj12PQ5wh/+NPIYa xLFnr3OpFMSFazJZK70omcIpDJXYeZA6wc1u8Upq/3plkIQvs/Bj4R+kQGx7bmQrb/eo ECIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747754087; x=1748358887; h=content-transfer-encoding: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=iSrpfL8xaFpRULZ/wjVaUfdkfzWgu438uQCRPW9kiS8=; b=EBy35WqcYDMGiyopJLv7QEGP6PGp1n93l5nwNXglfyxNrygsd4iqt1Rrg+NT23GaUm PaaSnqqRN7gtNzcCiOuxDEk4KXoenmmrZe+AGPkKelts2IpAl+Bmgv8iJY7GOsXsk0VJ ycpqv4X6xf5jmcnYz30++wUVfX/sijQTh/iHcCYDt7WvdkUFeeIQx+ascgto5f6ejB6t XpgflJlfn4EHQhtuzxRop7JiA8dXEiWIAd6ueMqpCXluTfY0how77ZFroSipQH+QO6tL lEH7OB9twwTTIoZujGEm9ADq3CJ3jca+YGpsQjAAAYFEWrlrh76W2KuinIf0qHosBXw8 1zXw== X-Forwarded-Encrypted: i=1; AJvYcCVOLEzQpFR/YmRgToQf0t3aP1U0YzQqyB+aB7b+K21cvBmOlUGbHkV4b2LvxBbdmdBXf477p7si1g==@kvack.org X-Gm-Message-State: AOJu0YwGqHeZ2kU4VZp5q3R0fZEE+Vx8uR+O4ZRWBkMP51fd9aV5Dfru sxZcHwI5lJWZDL62fqhkaGFx/QuvaiBt+F2VjbRT2g/6f5G0N0MYc4+VZ4pEtAiYHSEt2G74OP0 EM+qSbc1glXsTOc2Chp8qPShHwceFUPiDCGjSPMRQ X-Gm-Gg: ASbGncuYMIVnha6wB+zwZ35m2fQJjbNdBXrGeNjAv3GAzvdm8UpLnuBdmjC+00CD8cQ 8wcBiLF2QWNRPhipJUWdDPoXbPsf8D8MCcaGlvBJcRE6OUZxo2ANg+u09uuUxzar2XajVTT4jS6 AdFRC2sAPw2C+Sz/6u3+d/vD0TxzuK6tK0in9uLvKbiqs5mnMP4bDLf5QNWSVE5YuhbbxxaMeq X-Google-Smtp-Source: AGHT+IHqxMAqm9ksZ9pdmifguaGcuAgwy595ArLVy7NQeSIbtyAJtcB0AxKMULhl/n7xN7BfZzI9P4AZwv9k2z3819E= X-Received: by 2002:ac8:5a8e:0:b0:494:9777:4bd with SMTP id d75a77b69052e-495ff6d39d7mr10177501cf.3.1747754086275; Tue, 20 May 2025 08:14:46 -0700 (PDT) MIME-Version: 1.0 References: <20250520122547.1317050-1-usamaarif642@gmail.com> <20250520122547.1317050-2-usamaarif642@gmail.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 20 May 2025 08:14:35 -0700 X-Gm-Features: AX0GCFuD9buhC-dU4FNw-ogmprw-VWLbagGLuSevZ4KRV2INpyupQsgxAdo-Jk8 Message-ID: Subject: Re: [PATCH 2/2] mm: slub: only warn once when allocating slab obj extensions fails To: Shakeel Butt Cc: Usama Arif , Harry Yoo , Andrew Morton , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: sq6pohbuya18sjzpbys43q5876m88x48 X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 94258A0005 X-HE-Tag: 1747754087-425825 X-HE-Meta: U2FsdGVkX19Bt9/KPEmse8NTbKEshf+nWvggmAu5RaTra/qIOdosWUqicdrdRAhnmtl3aXOGtNUFyUqalFK7n1y1KNTaPFmWZtirSBZr6UMZZ7mgPLWEwDhcQsP4yq7OM2nCqDT4jqFrnA9e3YSgck2o5Is+biJkL2q1La/e2aY1UDl8+4/2tpcETb3p/2xZ1Z1ws8pRMmdDqIy2QU5qzEb6VknVwULZ4S0jaThcUi+epaSU7hpiXPwsf//cdaqTOrwnRm6yyPstURhqlRFUxVynZVuXMm07WRp/7GrcmtnWz1U+BisO0oanojlkCMgWdzPmgo6rSE0AMv+Ma6oF3DqCzXsJBVwslk/vOYfasD6vyWoBOoqDjN1ihIsEAQeSg4WP621qpqX0ZhEKG0QObXiMUY2VYKxIz+TmnenrGMnsDaSWmvSlWaLfDeEwFhQzYIyekQi2uWrwZuXkYJpAF+fm2DiLy8j+jjc+T0UvIYT1u7/mxR42v3i0M/imztYJDv+r6jhje8kY3KCbotOqenknttCZryw5y3oAyA59m5J9w0FWNMvVspDoxn1bS2vdk2W+o9kEcKWnGYEnBIWIhmdoSAR8sVr8pQCjpNEmGTlg/Ik006qoP2jsDs4h47NPM5OVOtudIT3sEH3Ksrl7/+Eoot3AzDr43P/VeosdedwnTNSe39dX5rjVRRqRdhNto3CGEhMxRIItZ6YzO08gzBzMSUwGn+6clUiCXNDGKkaz2qRn4WW7CbarRAamUVqtOYnQVcvajiHGDUoaEJeQZjIV3LnHS4HejMpGfcJM7+t+e8QvjHvC54Thaycx3r6NxZsfV2yvQZKM+h6+L4w5s/OyuxJ1IyJJV62fJSB8nGYQxgST74QwQPVr/7kQkQYrGl4Agb7xq35LH+Sd+GqADr2TTWJkEANzKgGaIjfB8+rSSWQAVjsRi3D7Nd/MI6AVK57wSj1ibSgvXgvj53d DcDZVspm 2BNX0u5HOBZcDiGHhpp3wLJ1WSoOlfVHeZBwZJHqGWFnte8omj97J20v4kkf5WemHDyIq+faQ9JSsxgnlTIZDhZWOyXYFehSe1f/dq4VjpysKWwwoEKl7qmY79F2cOwM28bLhpQyh9Rlrq4V5qn3NREx+z3VK4N1KaSQQBJHwRfi2Wel+3RhXHKyc3H6PqRL7Z3CFWPh85chM1uyfVYL4h8WRlXcTabL0DmaHiY8vN6iv6gOpAxmig+GWqKHB/TFjiHwbPfH508T0uXWhTLa7HxVGnIDSydL2AcsaIpdZ1zPC+qQ+XDvDhVv09w== 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 7:18=E2=80=AFAM Shakeel Butt wrote: > > 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-b7595150= 8f0a@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 =3D 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_ext= s > > returns non-zero. So WARN_ONCE should be ok? > > > > The difference is the impact on panic_on_warn users which are mostly > testing bots. Another difference is that pr_warn() does not spit out the call stack. > This warning is not actionable, so I agree with Harry to > covert this to pr_warn_once(). Makes sense. > > > > The coding style guide explicitly states that: > > >> Do not WARN lightly > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> > > >> WARN*() is intended for unexpected, this-should-never-happen situati= ons. > > >> WARN*() macros are not to be used for anything that is expected to h= appen > > >> during normal operation. These are not pre- or post-condition assert= s, > > >> 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 panic= ked > > > just because their kernel failed to allocate slab extension vectors, = which is > > > a totally normal situtation. > > > > > >> return NULL; > > >> -- > > >> 2.47.1 > > >> > > >> > > > > >