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 X-Spam-Level: X-Spam-Status: No, score=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD4EEC48BE6 for ; Mon, 14 Jun 2021 09:26:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4891661360 for ; Mon, 14 Jun 2021 09:26:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4891661360 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 760446B006C; Mon, 14 Jun 2021 05:26:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 710996B006E; Mon, 14 Jun 2021 05:26:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 562C76B0070; Mon, 14 Jun 2021 05:26:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id 208516B006C for ; Mon, 14 Jun 2021 05:26:51 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9BF3C8249980 for ; Mon, 14 Jun 2021 09:26:50 +0000 (UTC) X-FDA: 78251799780.04.425C0D7 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf01.hostedemail.com (Postfix) with ESMTP id 6E70E5001707 for ; Mon, 14 Jun 2021 09:26:41 +0000 (UTC) Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 803201FD33; Mon, 14 Jun 2021 09:26:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1623662808; h=from:from:reply-to: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; bh=YnaGxUPiC83+WV/hOpo0imRl20Dx5ZKVdkRLysC5w+4=; b=LfbCVcYwkshECAJCCsjELcY/LVbWqcp0PJPpdG+syzf+AL7ikxXvldQWXjFTz0U97i+lbB ngdgzHlbGLtCWR9QJxlS+ZRYoApHpO3K8OblzDEzbp3nHSv63d3HS5sFxZy8jJMFuuOWja EG+J4H2x3rKVhfRWq+NFbdOIaoru7iI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1623662808; h=from:from:reply-to: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; bh=YnaGxUPiC83+WV/hOpo0imRl20Dx5ZKVdkRLysC5w+4=; b=fa+ydK68gbxJa9XQR9sn0Gx3mFgSgF1g3v3t9rv5WWkAkpO8zWL4EevZ8V2c8f47njJqul fG3W6jor8k5DqiCQ== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 5DA8C118DD; Mon, 14 Jun 2021 09:26:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1623662808; h=from:from:reply-to: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; bh=YnaGxUPiC83+WV/hOpo0imRl20Dx5ZKVdkRLysC5w+4=; b=LfbCVcYwkshECAJCCsjELcY/LVbWqcp0PJPpdG+syzf+AL7ikxXvldQWXjFTz0U97i+lbB ngdgzHlbGLtCWR9QJxlS+ZRYoApHpO3K8OblzDEzbp3nHSv63d3HS5sFxZy8jJMFuuOWja EG+J4H2x3rKVhfRWq+NFbdOIaoru7iI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1623662808; h=from:from:reply-to: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; bh=YnaGxUPiC83+WV/hOpo0imRl20Dx5ZKVdkRLysC5w+4=; b=fa+ydK68gbxJa9XQR9sn0Gx3mFgSgF1g3v3t9rv5WWkAkpO8zWL4EevZ8V2c8f47njJqul fG3W6jor8k5DqiCQ== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id wDfmFNggx2CCSQAALh3uQQ (envelope-from ); Mon, 14 Jun 2021 09:26:48 +0000 To: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Andrew Morton Cc: kernel test robot , kbuild-all@lists.01.org, Linux Memory Management List , Nathan Chancellor , Nick Desaulniers References: <202106051442.G1VJubTz-lkp@intel.com> <20210606110839.GA13828@hyeyoo> <20210607122550.GA752464@hyeyoo> <06af75da-ffe9-7070-1da8-bcb2cb7881d2@suse.cz> <20210607154957.GB927582@hyeyoo> <6e1d48f2-409c-0a71-4d04-a907fe4183b8@suse.cz> <20210608170528.GA28015@hyeyoo> <2d2d792e-e189-99a4-36cb-f1473a4df9ad@suse.cz> <20210608184501.GA5505@hyeyoo> <513f82e6-175c-d040-691c-5d0e7dacfb83@suse.cz> From: Vlastimil Babka Subject: [PATCH FIX -next] Re: [linux-next:master 7012/7430] include/linux/compiler_types.h:328:38: error: call to '__compiletime_assert_183' declared with attribute error: unexpected size in kmalloc_index() Message-ID: Date: Mon, 14 Jun 2021 11:26:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LfbCVcYw; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=fa+ydK68; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LfbCVcYw; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=fa+ydK68; spf=pass (imf01.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6E70E5001707 X-Stat-Signature: 7j46gbf4i5sdj9ro4rq711dw8hxg91of X-HE-Tag: 1623662801-41171 Content-Transfer-Encoding: quoted-printable 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: On 6/12/21 2:19 AM, Hyeonggon Yoo wrote: > On Sat, Jun 12, 2021, 8:59 AM Vlastimil Babka > wrote: >=20 >=20 > > But little bit worried :( > > The code is getting too complicated... > > How do you think? >=20 > Yeah, I expected that problems like this could occur as we're pokin= g at some > rare corner cases of compiler implementations here. But if that lea= ds to fixes > in compilers, good for everyone I'd say. >=20 > So I would try this, even if it becomes complicated. >=20 >=20 > Okay, I see the code is okay, but one thing to suggest: > =C2=A0 =C2=A0 The problem already existed in kmalloc_node before the pa= tch And we found it > by adding BUILD_BUG_ON in kmalloc_index. >=20 > =C2=A0 =C2=A0 So I suggest adding the condition in kmalloc_node. How ab= out this? >=20 If we add it to kmalloc_node() it means with CONFIG_PROFILE_ALL_BRANCHES = we will not be using the compile-time optimized kmalloc_index anywhere. But we ge= t the error only with one file, so in all the other cases the gcc optimizer see= ms to work fine even with this config enabled. Placing the condition to kmalloc_index() thus limits it only to cases where it doesn't work. As you indicated you would be away starting this week, let me just sent t= he fix right now so we stop getting the -next reports: ----8<---- >From 56c164dc5c0485c2e133190c0f56e4069844ad62 Mon Sep 17 00:00:00 2001 From: Vlastimil Babka Date: Mon, 14 Jun 2021 11:16:03 +0200 Subject: [PATCH]=20 mm-slub-change-run-time-assertion-in-kmalloc_index-to-compile-time-fix-3 Kernel test robot reports a false-positive compile-time assert while comp= iling kernel/bpf/local_storage.c In file included from : In function 'kmalloc_index', inlined from 'kmalloc_node' at include/linux/slab.h:572:20, inlined from 'bpf_map_kmalloc_node.isra.0.part.0' at include/linux= /bpf.h:1319:9: >> >> include/linux/compiler_types.h:328:38: error: call to '__compiletim= e_assert_183' declared with attribute error: unexpected size in kmalloc_i= ndex() 328 | _compiletime_assert(condition, msg, __compiletime_assert_, __= COUNTER__) | ^ include/linux/compiler_types.h:309:4: note: in definition of macro '__= compiletime_assert' 309 | prefix ## suffix(); \ | ^~~~~~ include/linux/compiler_types.h:328:2: note: in expansion of macro '_co= mpiletime_assert' 328 | _compiletime_assert(condition, msg, __compiletime_assert_, __= COUNTER__) | ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compilet= ime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond)= , msg) | ^~~~~~~~~~~~~~~~~~ include/linux/slab.h:389:2: note: in expansion of macro 'BUILD_BUG_ON_= MSG' 389 | BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); | ^~~~~~~~~~~~~~~~ This only happens with CONFIG_PROFILE_ALL_BRANCHES enabled. Informal conversation with gcc developers suggest that this config pushes the opti= mizer to a corner case where in kmalloc_node() the 'size' is considered a builtin-constant and thus kmalloc_index() is chosen, but later in kmalloc_index() the notion of compile-time constant is lost and thus the compiletime assert becomes reachable. While there's plan to submit a proper gcc bug report with reduced testcas= e, for now add CONFIG_PROFILE_ALL_BRANCHES to the list of situations where w= e keep using the runtime BUG_ON() instead of compile-time assert. This is a 3rd fix for mmotm patch mm-slub-change-run-time-assertion-in-kmalloc_index-to-compile-time.patch [1] https://lore.kernel.org/linux-mm/202106051442.G1VJubTz-lkp@intel.com/ Reported-by: kernel test robot Signed-off-by: Vlastimil Babka --- include/linux/slab.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index 8d8dd8571261..083f3ce550bc 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -413,7 +413,8 @@ static __always_inline unsigned int __kmalloc_index(s= ize_t size, if (size <=3D 16 * 1024 * 1024) return 24; if (size <=3D 32 * 1024 * 1024) return 25; =20 - if ((IS_ENABLED(CONFIG_CC_IS_GCC) || CONFIG_CLANG_VERSION >=3D 110000) = && size_is_constant) + if ((IS_ENABLED(CONFIG_CC_IS_GCC) || CONFIG_CLANG_VERSION >=3D 110000) + && !IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) && size_is_constant) BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); else BUG(); --=20 2.32.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2497138050855736315==" MIME-Version: 1.0 From: Vlastimil Babka To: kbuild-all@lists.01.org Subject: [PATCH FIX -next] Re: [linux-next:master 7012/7430] include/linux/compiler_types.h:328:38: error: call to '__compiletime_assert_183' declared with attribute error: unexpected size in kmalloc_index() Date: Mon, 14 Jun 2021 11:26:48 +0200 Message-ID: In-Reply-To: List-Id: --===============2497138050855736315== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 6/12/21 2:19 AM, Hyeonggon Yoo wrote: > On Sat, Jun 12, 2021, 8:59 AM Vlastimil Babka > wrote: > = > = > > But little bit worried :( > > The code is getting too complicated... > > How do you think? > = > Yeah, I expected that problems like this could occur as we're poking = at some > rare corner cases of compiler implementations here. But if that leads= to fixes > in compilers, good for everyone I'd say. > = > So I would try this, even if it becomes complicated. > = > = > Okay, I see the code is okay, but one thing to suggest: > =C2=A0 =C2=A0 The problem already existed in kmalloc_node before the patc= h And we found it > by adding BUILD_BUG_ON in kmalloc_index. > = > =C2=A0 =C2=A0 So I suggest adding the condition in kmalloc_node. How abou= t this? > = If we add it to kmalloc_node() it means with CONFIG_PROFILE_ALL_BRANCHES we= will not be using the compile-time optimized kmalloc_index anywhere. But we get = the error only with one file, so in all the other cases the gcc optimizer seems= to work fine even with this config enabled. Placing the condition to kmalloc_index() thus limits it only to cases where it doesn't work. As you indicated you would be away starting this week, let me just sent the= fix right now so we stop getting the -next reports: ----8<---- >>From 56c164dc5c0485c2e133190c0f56e4069844ad62 Mon Sep 17 00:00:00 2001 From: Vlastimil Babka Date: Mon, 14 Jun 2021 11:16:03 +0200 Subject: [PATCH] = mm-slub-change-run-time-assertion-in-kmalloc_index-to-compile-time-fix-3 Kernel test robot reports a false-positive compile-time assert while compil= ing kernel/bpf/local_storage.c In file included from : In function 'kmalloc_index', inlined from 'kmalloc_node' at include/linux/slab.h:572:20, inlined from 'bpf_map_kmalloc_node.isra.0.part.0' at include/linux/b= pf.h:1319:9: >> >> include/linux/compiler_types.h:328:38: error: call to '__compiletime_= assert_183' declared with attribute error: unexpected size in kmalloc_index= () 328 | _compiletime_assert(condition, msg, __compiletime_assert_, __CO= UNTER__) | ^ include/linux/compiler_types.h:309:4: note: in definition of macro '__co= mpiletime_assert' 309 | prefix ## suffix(); \ | ^~~~~~ include/linux/compiler_types.h:328:2: note: in expansion of macro '_comp= iletime_assert' 328 | _compiletime_assert(condition, msg, __compiletime_assert_, __CO= UNTER__) | ^~~~~~~~~~~~~~~~~~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletim= e_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), = msg) | ^~~~~~~~~~~~~~~~~~ include/linux/slab.h:389:2: note: in expansion of macro 'BUILD_BUG_ON_MS= G' 389 | BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); | ^~~~~~~~~~~~~~~~ This only happens with CONFIG_PROFILE_ALL_BRANCHES enabled. Informal conversation with gcc developers suggest that this config pushes the optimi= zer to a corner case where in kmalloc_node() the 'size' is considered a builtin-constant and thus kmalloc_index() is chosen, but later in kmalloc_index() the notion of compile-time constant is lost and thus the compiletime assert becomes reachable. While there's plan to submit a proper gcc bug report with reduced testcase, for now add CONFIG_PROFILE_ALL_BRANCHES to the list of situations where we keep using the runtime BUG_ON() instead of compile-time assert. This is a 3rd fix for mmotm patch mm-slub-change-run-time-assertion-in-kmalloc_index-to-compile-time.patch [1] https://lore.kernel.org/linux-mm/202106051442.G1VJubTz-lkp(a)intel.com/ Reported-by: kernel test robot Signed-off-by: Vlastimil Babka --- include/linux/slab.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index 8d8dd8571261..083f3ce550bc 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -413,7 +413,8 @@ static __always_inline unsigned int __kmalloc_index(siz= e_t size, if (size <=3D 16 * 1024 * 1024) return 24; if (size <=3D 32 * 1024 * 1024) return 25; = - if ((IS_ENABLED(CONFIG_CC_IS_GCC) || CONFIG_CLANG_VERSION >=3D 110000) &&= size_is_constant) + if ((IS_ENABLED(CONFIG_CC_IS_GCC) || CONFIG_CLANG_VERSION >=3D 110000) + && !IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) && size_is_constant) BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); else BUG(); -- = 2.32.0 --===============2497138050855736315==--