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 32CCBC3DA45 for ; Thu, 11 Jul 2024 17:06:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B90EC6B00A0; Thu, 11 Jul 2024 13:06:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B41336B00A1; Thu, 11 Jul 2024 13:06:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E2486B00A2; Thu, 11 Jul 2024 13:06:37 -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 81B6C6B00A0 for ; Thu, 11 Jul 2024 13:06:37 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 224A5A0792 for ; Thu, 11 Jul 2024 17:06:37 +0000 (UTC) X-FDA: 82328100834.09.9DAA383 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf08.hostedemail.com (Postfix) with ESMTP id 353FC160024 for ; Thu, 11 Jul 2024 17:06:35 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EiJWqDlk; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@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=1720717551; 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=djklYk9rWCjm2tsWgbZ32mQ8UgJBx4pRhVg9VXDIihA=; b=F7E0d8prnIs0HqRCAFlb3GNpcjLmcXQA0S/YrfHWJNCmIBVHq4bUXM8iTiruDTo9dA85af o7CO6hYf8lUPC110nmOqfpNvw6cbk2o45jW1rdsxFRITWNm+JBfNlduUEqbZXu0SrYYxuc twAUq5GIeKv1U7qL2Hmyrg6tH8OIIAI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EiJWqDlk; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720717551; a=rsa-sha256; cv=none; b=X24cP0FjwcJiwEPaTWG2n+hfisZ+Wyr+Dla7jDo4cYtwrdvo9JnplYK85JOm5dmE0kO6mR ZxWUliHeC6l09en8ZxgzqLN+2N2lmQo9W3pqjvv0856kupZQOPWzS4KpjOYaayiSzATMXZ d++npNVr4eoY7z6cP/fJ7/53N3MpLCg= Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-dfdb6122992so1056527276.3 for ; Thu, 11 Jul 2024 10:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1720717594; x=1721322394; 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=djklYk9rWCjm2tsWgbZ32mQ8UgJBx4pRhVg9VXDIihA=; b=EiJWqDlkOc8h7w/pRa7V8y6r08X4QgMqhAJ4nANpMIyR6eZiD54JrickondiM1hCJ/ 7Tc98piLGPWa7i9/2/8gdhKd40CzhiP3hwqO1iLtdFFXdl+EcbH0D7rPRo8Oj+0fXwbY MtUyi7K2y1mFfKLt2dYzRF5ZyhGKeZvcYoMk3oVSYI/2ngAD0WIA9SJv2VYZRvYZF4V5 iRysTdfTa+f1TbR/KZaQ8TPHvQxtaRyVRIosPB2L8+2IHGa7p0a9uSEZ0mEu9i6GUSJF 2TsoeV1YZ8/DZUYxBOUI9JLoSYGPhTAzw18UZH9vYlXFj++En5eg7EWtMbvMP5GLOwE3 giBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720717594; x=1721322394; 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=djklYk9rWCjm2tsWgbZ32mQ8UgJBx4pRhVg9VXDIihA=; b=VPmK0P6iXGK3BWskJ4kGl1+I4S0n5/MMyj43/iyvIvf1+2o9flJSROITQwXtleTYJu raO+rHS+91VeWh8JQdYklALOFYNCVWVH6cH+7wo9Zj6C1j5zF4362BN2CKSfc+I2s3l9 cU0Xer/3J1FzLBVtT2o7vqVCBDP+g2wgwXKSDMzT4spfXlaGacLjBJY0yv+eHolgSQtB Rrj4ZONi04YbrySxLjH3buA7Gw668fZlcGhXdt/bUWDnoDe+m9IS044aHfNpRXBloOu8 MUNtEmKaudQaRsZsldis7B8uRoYf2GxtzqqLJWyCpADqJGXD0oCSJ6Ty+QAkJEV5wcwY +Z3g== X-Forwarded-Encrypted: i=1; AJvYcCVgkh8gi4HXJo97+ci+yoQ0RGxB6uCM6Jk8q3TUWwB1YoD5mOP/0heFRWKeQv4ha5DlTnuymklpGab7mYFG9MFr60Q= X-Gm-Message-State: AOJu0YzkIc8NnPSXymvRpDsnmFwUiVrGavjugFGLdW+IVA+2ojlgb/p2 hr+FOaP0vbfMGFaDPaZoEzMKPKCBdVqGShfKwtoexGk90yLmAwHwv/zLAD3lE1JU85d9Ocgt66D mOd6QPTbutQN8dVezB7bT7wA6RF6w3Wfmrih5 X-Google-Smtp-Source: AGHT+IEjLTuYW3rMjiWDPSDFo/eiUXPqxmY1jhWYiTkKdjmVVxgLDTfX3dkdkMaURNMZn39k8dgTfzzNTZOG6FO4Tuo= X-Received: by 2002:a0d:ed45:0:b0:646:5ae1:b74d with SMTP id 00721157ae682-658f0dc3243mr98784117b3.48.1720717593956; Thu, 11 Jul 2024 10:06:33 -0700 (PDT) MIME-Version: 1.0 References: <20240710025418.394321-1-sxwjean@me.com> <20240710150154.GA1684801@thelio-3990X> <4b533d6c-b2f3-49eb-a7fb-807af482def8@suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 11 Jul 2024 10:06:19 -0700 Message-ID: Subject: Re: [PATCH] mm/slub: quiet the clang warning with -Wunused-function enabled To: Vlastimil Babka Cc: Nathan Chancellor , Matthew Wilcox , sxwjean@me.com, cl@linux.co, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, xiongwei.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel test robot , llvm@lists.linux.dev, Nick Desaulniers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 353FC160024 X-Stat-Signature: 7e4xndax43c5enzg6qcjekrjt7iuzcrp X-Rspam-User: X-HE-Tag: 1720717595-585669 X-HE-Meta: U2FsdGVkX1+mzuzBETw13HxwzxsPp3/08167kD9iBiVE3+k1Q6c7OGpQ95Kcirc9qjRbvg7tkgtTzU7bHRrw1MafVpbLnONxE19N2IJDlQPvZciVYo+5VSYZEau+PMb4Dxo76Vb2W1MldUCFPKDI0k4lZ+XzF6yP5a3OZMP2QSoM8WSZOTdxsNOL+6y3G96HUwXPR55wm137ClUUA4jEWk0/3T2HOveHwRMSYMfXefZ00trXcpmSoeTAcpGax+rRgpV8MTtURlcvWJD2OB91tsmS2AAN7/mQT2y7DYcks8GLibj825km1l7BrqW15MR2yYBVaGozqo6PKkgYR+LHtsNwsMKHI3VNenZoeEFwV5tVjtXS4Gt4OG+/nSr6VQ3MpjDShXx2UAXIycARUbM7ZdaLTAXO4gT4fP/PQ+xofoPNiwdc74TuEBufd4jWy1M0CDuue0BIBN1XwxGb7X5ba5Xs5SGMbQdVlZiufm0NKplgBa6UVaBIhl95/X9HIwAfG3dDUMNfVXR2pGBlNlyfONuWqsaeQX6DYknySAXE7bYPOgr8fuuzNiI4piReUcOaDM5OQTIkcQdo+xnAASpxFHfT5G266CQ9i7kbMyPtZi4cmJBGQaTwk3s4y6lvTJhmZ1HZPySydrSVSFzhLLRttnayh9QtftzWhupHRpOlYgGdtRJ/g0IRlqvGbYsFQBr7FxnWhf9ZgE5VWRBS+iyhpDtD3lYdKwnvbngTCwRVugYxzDh67Ek/vZUpP7Llz/BuKwoHfKqeEOMTzRXPsavWYDxuKCsA/Sh/cAdGCtK8756i/n5fVEW6isS3NXv0kCU7s6Hlzgm28XsDHNqdvJaaYCL1t2KqbiktUIJSQuCvZ4NuHMjeeLZ0M9G0e739Qk27DUeKZNlsbr4dTYkxxfoHR2RLPVsBA1/9vmcrHZRoBbrt1NsSh5ARs21YBs/s9FVoDEvQTdyHC4znsxqsxXI PQ5hn4B3 5d9ZiTUNXdqgjQc4m/FNotIuljwWL87Gvcbi/1/goSrOScZrrsCAPh9IAp8Gncm3NyjSmVs6OkadvCFaI/Hg3MT28OuMpP5aTOc5J91azWuFMAGqzDk2m4u4y0QJxNwyvSeh+nxtTXcrTwMZsBVqijCZpqUwrgwTpJIioY0ExYDNCYlqNWCL98gFWjHynDuvwSG2xhb/F67r6O+cORuO8nqTJd5zx+YNZpy8ZMD4XpxsZGtiaYoCi2lNfep/1/iMbiTw9Vi75BO7diXSPnfq0OVqUnRtuddgOpvToreZAiTmX3iSx+C0bhv57YrRhQNDqUwgykxtJ6zr7jP7N8qWsPugOilEfuIwRCkumWlOXeMq5VO24Fe9N3mTNLQ== 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 Thu, Jul 11, 2024 at 6:56=E2=80=AFAM Suren Baghdasaryan wrote: > > On Thu, Jul 11, 2024 at 12:43=E2=80=AFAM Vlastimil Babka = wrote: > > > > On 7/10/24 11:40 PM, Suren Baghdasaryan wrote: > > > On Wed, Jul 10, 2024 at 8:02=E2=80=AFAM Nathan Chancellor wrote: > > >> > > >> On Wed, Jul 10, 2024 at 04:03:33AM +0100, Matthew Wilcox wrote: > > >> > On Wed, Jul 10, 2024 at 10:54:18AM +0800, sxwjean@me.com wrote: > > >> > > From: Xiongwei Song > > >> > > > > >> > > The only user of prepare_slab_obj_exts_hook() is > > >> > > alloc_tagging_slab_alloc_hook(), which can build with > > >> > > CONFIG_MEM_ALLOC_PROFILING enabled. So, the warning was triggerr= ed > > >> > > when disabling CONFIG_MEM_ALLOC_PROFILING. Let's add "__maybe_un= used" > > >> > > for prepare_slab_obj_exts_hook(). > > >> > > > >> > Perhaps instead clang can be fixed to match gcc's behaviour? > > >> > > >> Clang only differs from GCC on warning for unused static inline func= tions in .c > > >> files, not .h files. The kernel already handles this in > > >> include/linux/compiler_types.h but it disables this workaround for W= =3D1 to catch > > >> unused functions like this as a result of commit 6863f5643dd7 ("kbui= ld: allow > > >> Clang to find unused static inline functions for W=3D1 build"): > > >> > > >> /* > > >> * GCC does not warn about unused static inline functions for -Wunus= ed-function. > > >> * Suppress the warning in clang as well by using __maybe_unused, bu= t enable it > > >> * for W=3D1 build. This will allow clang to find unused functions. = Remove the > > >> * __inline_maybe_unused entirely after fixing most of -Wunused-func= tion warnings. > > >> */ > > >> #ifdef KBUILD_EXTRA_WARN1 > > >> #define __inline_maybe_unused > > >> #else > > >> #define __inline_maybe_unused __maybe_unused > > >> #endif > > >> > > >> So I don't really think there is much for clang to do here and I thi= nk having > > >> the ability to find unused static inline functions in .c files is us= eful (you > > >> might disagree, perhaps a revert could still be discussed). I guess > > >> IS_ENABLED() can't be used there, so it seems like either taking thi= s patch, > > >> ignoring the warning, or refactoring the code in some other way are = the only > > >> options I see. > > > > > > I think this is the consequence of the recent refactoring I've done i= n > > > https://lore.kernel.org/all/20240704135941.1145038-1-surenb@google.co= m/. > > > There should be a cleaner way to fix this. I'll post it later today o= r > > > tomorrow morning. > > > > Yeah looks like the non-empty prepare_slab_obj_exts_hook() could move t= o the > > #ifdef CONFIG_MEM_ALLOC_PROFILING section above > > alloc_tagging_slab_alloc_hook() and the empty one just removed. > > Exactly my plan. I'll post a patch once I reach the office. Actually I was wrong and the problem exists even without my refactoring in [1]. I posted the fix at [2] and I based it on slab/for-next because that's the only branch that contains [1]. Not because [2] requires [1] but because they are changing adjacent code, so would create merge problems if merged separately. [1] https://lore.kernel.org/all/20240704135941.1145038-1-surenb@google.com/ [2] https://lore.kernel.org/all/20240711170216.1149695-1-surenb@google.com/ > > > > > > Thanks, > > > Suren. > > > > > >> > > >> > > Reported-by: kernel test robot > > >> > > Closes: https://lore.kernel.org/oe-kbuild-all/202407050845.zNONq= auD-lkp@intel.com/ > > >> > > Signed-off-by: Xiongwei Song > > >> > > --- > > >> > > mm/slub.c | 4 ++-- > > >> > > 1 file changed, 2 insertions(+), 2 deletions(-) > > >> > > > > >> > > diff --git a/mm/slub.c b/mm/slub.c > > >> > > index ce39544acf7c..2e26f20759c0 100644 > > >> > > --- a/mm/slub.c > > >> > > +++ b/mm/slub.c > > >> > > @@ -2027,7 +2027,7 @@ static inline bool need_slab_obj_ext(void) > > >> > > return false; > > >> > > } > > >> > > > > >> > > -static inline struct slabobj_ext * > > >> > > +static inline struct slabobj_ext * __maybe_unused > > >> > > prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, v= oid *p) > > >> > > { > > >> > > struct slab *slab; > > >> > > @@ -2068,7 +2068,7 @@ static inline bool need_slab_obj_ext(void) > > >> > > return false; > > >> > > } > > >> > > > > >> > > -static inline struct slabobj_ext * > > >> > > +static inline struct slabobj_ext * __maybe_unused > > >> > > prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, v= oid *p) > > >> > > { > > >> > > return NULL; > > >> > > -- > > >> > > 2.34.1 > > >> > > > > >> > > > >