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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 80C62C47082 for ; Tue, 8 Jun 2021 17:27:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1872061375 for ; Tue, 8 Jun 2021 17:27:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1872061375 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 8E55F6B006C; Tue, 8 Jun 2021 13:27:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86E4D6B006E; Tue, 8 Jun 2021 13:27:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 672416B0070; Tue, 8 Jun 2021 13:27:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) by kanga.kvack.org (Postfix) with ESMTP id 2C12D6B006C for ; Tue, 8 Jun 2021 13:27:55 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B042FA2D5 for ; Tue, 8 Jun 2021 17:27:54 +0000 (UTC) X-FDA: 78231239268.36.A85B9E3 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf24.hostedemail.com (Postfix) with ESMTP id 88029A000252 for ; Tue, 8 Jun 2021 17:27:50 +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 9D70A1FD2A; Tue, 8 Jun 2021 17:27:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1623173272; 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=Ue7M16lvbm0q3+f/MnAHqFQR5oIN66SfRAyH5EnLIis=; b=RxGFTKKpIVV6nABJCYsf7f+N7HM/EUQvAVFWbiQx63JMezEf0UY5WnS7ebgzKl5HS7/bcU pRgnkwmm90fR/IpWpuY3z3Pudav2DfBS/V+odnN9fbF7Ee9qWbZ09UY4DDJIH0LFDm+zWo AaYM7zcAZQ+cG9/ED6kfiOwwyhve2dI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1623173272; 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=Ue7M16lvbm0q3+f/MnAHqFQR5oIN66SfRAyH5EnLIis=; b=UB8ewC1Hx7MrkYfyzCMy1JHyjITpbzNco3vZw95y09PesNHKylJ7Wp0AMHo03COo2bf5TP nPxBwXtG+042bhBA== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 7A1C5118DD; Tue, 8 Jun 2021 17:27:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1623173272; 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=Ue7M16lvbm0q3+f/MnAHqFQR5oIN66SfRAyH5EnLIis=; b=RxGFTKKpIVV6nABJCYsf7f+N7HM/EUQvAVFWbiQx63JMezEf0UY5WnS7ebgzKl5HS7/bcU pRgnkwmm90fR/IpWpuY3z3Pudav2DfBS/V+odnN9fbF7Ee9qWbZ09UY4DDJIH0LFDm+zWo AaYM7zcAZQ+cG9/ED6kfiOwwyhve2dI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1623173272; 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=Ue7M16lvbm0q3+f/MnAHqFQR5oIN66SfRAyH5EnLIis=; b=UB8ewC1Hx7MrkYfyzCMy1JHyjITpbzNco3vZw95y09PesNHKylJ7Wp0AMHo03COo2bf5TP nPxBwXtG+042bhBA== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id xhXLHJiov2CycQAALh3uQQ (envelope-from ); Tue, 08 Jun 2021 17:27:52 +0000 To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: kernel test robot , kbuild-all@lists.01.org, Linux Memory Management List , Andrew Morton 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> From: Vlastimil Babka Subject: 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: <2d2d792e-e189-99a4-36cb-f1473a4df9ad@suse.cz> Date: Tue, 8 Jun 2021 19:27:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <20210608170528.GA28015@hyeyoo> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=RxGFTKKp; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=UB8ewC1H; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=RxGFTKKp; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=UB8ewC1H; dmarc=none; spf=pass (imf24.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Stat-Signature: fyo5uzfr4ko63oembct7bp3rw9juc1ye X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 88029A000252 X-HE-Tag: 1623173270-554711 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/8/21 7:05 PM, Hyeonggon Yoo wrote: > On Tue, Jun 08, 2021 at 09:57:18AM +0200, Vlastimil Babka wrote: >> On 6/7/21 5:49 PM, Hyeonggon Yoo wrote: >> > On Mon, Jun 07, 2021 at 05:27:27PM +0200, Vlastimil Babka wrote: >> >> On 6/7/21 2:25 PM, Hyeonggon Yoo wrote: >> >> > On Mon, Jun 07, 2021 at 01:40:02PM +0200, Vlastimil Babka wrote: >> >> >> On 6/6/21 1:08 PM, Hyeonggon Yoo wrote: >> >> >> > On Sat, Jun 05, 2021 at 02:10:46PM +0800, kernel test robot wr= ote: >> >> >>=20 >> >> >> But what exactly is the gcc problem here? >> >> >> Did you have to reproduce it with specific gcc version and/or ar= chitecture? >> >> >>=20 >> >> >=20 >> >> > Before replying, I should say that I'm not an expert on gcc. >> >> > I just tried some ways to fix the error, and it seemed to me that >> >> > gcc is doing something wrong. >> >>=20 >> >> I'm involving my gcc colleagues, will report results... >>=20 >> Well, it seems the bot's .config included CONFIG_PROFILE_ALL_BRANCHES = as the >> main factor to trigger the problem. And (according to my colleagues) >=20 > Wow, AWESOME! How did your colleague find it? that was a big hint for m= e. > when CONFIG_PROFILE_ALL_BRANCHES is not set, it doesn't make an error. Well, we started with me doing "make kernel/bpf/local_storage.i" to creat= e a preprocessed C source that can be copied out and debugged outside of the = whole kernel build context. I send that to my colleague and he reduced the test= case using cvise: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction While the reduction wasn't successful in preserving enough of the testcas= e, from the result it was clear that there was lots of ftrace_branch_data stuff a= nd so it was easy to find this is due to CONFIG_PROFILE_ALL_BRANCHES. >> it might add too many instrumented if conditions to sustain the builti= n-constant >> tracking, which is not unlimited, or interact with optimizations in so= me other >> corner case way. >=20 >> I guess we could add IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) to the li= st of >> conditions that excludes using BUILD_BUG_ON_MSG(). >=20 > Well I wanted to understand how CONFIG_PROFILE_ALL_BRANCHES excludes > BUILD_BUG_ON This is gcc's preprocessor output. >=20 > So let's start from what CONFIG_PROFILE_ALL_BRANCHES does. >=20 > #ifdef CONFIG_PROFILE_ALL_BRANCHES > /* > * "Define 'is'", Bill Clinton > * "Define 'if'", Steven Rostedt > */ > #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) = ) >=20 > #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __t= race_if_value(cond)) >=20 > #define __trace_if_value(cond) ({ \ > static struct ftrace_branch_data \ > __aligned(4) \ > __section("_ftrace_branch") \ > __if_trace =3D { \ > .func =3D __func__, \ > .file =3D __FILE__, \ > .line =3D __LINE__, \ > }; \ > (cond) ? \ > (__if_trace.miss_hit[1]++,1) : \ > (__if_trace.miss_hit[0]++,0); \ > }) >=20 > #endif /* CONFIG_PROFILE_ALL_BRANCHES */ >=20 > it seems it records non-constant condition's hit or miss. > if cond is constant, do nothing. else, records its hit or miss at > runtime. >=20 > then let's look at kmalloc_node, which is called by bpf_map_kmalloc_nod= e. >=20 > static inline __attribute__((__gnu_inline__)) __attribute__((__unused__= )) __attribute__((no_instrument_function)) __attribute__((__always_inline= __))=20 > void *kmalloc_node(size_t size, gfp_t flags, int node){ >=20 > if ( (__builtin_constant_p( > !!(__builtin_constant_p(size) > && size <=3D (1UL << ((11 + 12 - 1) <=3D 25 ? (11 + 12 - 1) : 25= )))) > ? (!!(__builtin_constant_p(size) && size <=3D (1UL << ((11 = + 12 - 1) <=3D 25 ? (11 + 12 - 1) : 25)))) > : ({=20 > static struct ftrace_branch_data __attribute__ ((__aligned__(4))) __= attribute__((__section__("_ftrace_branch")))=20 > __if_trace =3D=20 > { .func =3D __func__, > .file =3D "include/linux/slab.h", > .line =3D 601, > }; > (!!(__builtin_constant_p(size) && size <=3D (1UL << ((11 + 12 - 1) <= =3D 25 ? (11 + 12 - 1) : 25))))=20 > ? (__if_trace.miss_hit[1]++,1)=20 > : (__if_trace.miss_hit[0]++,0); })) ) > { > unsigned int i =3D __kmalloc_index(size, true); >=20 > It seems that gcc evaluates >=20 > __builtin_constant_p( > !!(builtin_constant_p(size) > && size <=3D KMALLOC_MAX_CACHE_SIZE) > ) > as true. >=20 > mm.. when the size passed to bpf_map_kmalloc_node is not constant, > (__builtin_constant_p(size) && size <=3D KMALLOC_MAX_CACHE_SIZE) is fal= se. > then __builtin_constant_p(!!false) is true. So it calls kmalloc_index. >=20 > what change should be made? > just checking CONFIG_PROFILE_ALL_BRANCHES to kmalloc_index's if conditi= on > doesn't make sense, because kmalloc_node is not working as expected. If I understood my colleagues right, the problem is that, while kmalloc_i= ndex() seems to contains a number of *independent* "if (size <=3D X) conditions = in a sequence, the machinery of CONFIG_PROFILE_ALL_BRANCHES turns it to a deep= ly nested if-then-else { if-then-else { if-then-else {...}}} thing (in fact = using the ternary operators, not if-then-else). At some point of the deep nesti= ng gcc "forgets" that __builtin_constant_p() is true and starts behaving as if i= t wasn't. Without CONFIG_PROFILE_ALL_BRANCHES it's able to keep track of it fine. > Plus, BUILD_BUG_ON_MSG seems not working with clang. > Below is generated by clang 11.0.0 preprocessor, when compiling > mm/kfence/kfence_test.o >=20 > Well, I'm going to read more code on BUILD_BUG_XXX family, > but if it doens't work on clang, we should change condition that we > made. >=20 > if ( (__builtin_constant_p(!!((0 || 110000 >=3D 110000) && size_is_cons= tant)) ? (!!((0 || 110000 >=3D 110000) && size_is_constant)) : ({ static = struct ftrace_branch_data __attribute__((__aligned__(4))) __attribute__((= __section__("_ftrace_branch"))) __if_trace =3D { .func =3D __func__, .fil= e =3D "include/linux/slab.h", .line =3D 416, }; (!!((0 || 110000 >=3D 110= 000) && size_is_constant)) ? (__if_trace.miss_hit[1]++,1) : (__if_trace.m= iss_hit[0]++,0); })) ) > do { >=20 >=20 > extern void __compiletime_assert_131(void) ; > // here - compiletime_assert_131 does NOTHING It doesn't seem to do nothing? see below > if ( (__builtin_constant_p(!!(!(!(1)))) > ? (!!(!(!(1)))) > : ({ static struct ftrace_branch_data __attribute__((__al= igned__(4))) __attribute__((__section__("_ftrace_branch"))) __if_trace =3D= { .func =3D __func__, .file =3D "include/linux/slab.h", .line =3D 417, }= ; (!!(!(!(1)))) ? (__if_trace.miss_hit[1]++,1) : (__if_trace.miss_hit[0]+= +,0); })) ) __compiletime_assert_131(); } while (0); The thing above seems to be exactly the "if (!(condition)) prefix ## suffix(); } while (0)" as the definition you posted below. Anyway, you can verify that clang works by commenting out the highest siz= e checks and passing a constant size that makes it reach the BUILD_BUG_ON_= MSG() ? > else > do { do { } while(0); do { asm __inline volatile("1:\t" ".byte 0x0f, = 0x0b" "\n" ".pushsection __bug_table,\"aw\"\n" "2:\t" ".long " "1b" " - 2= b" "\t# bug_entry::bug_addr\n" "\t.word %c0" "\t# bug_entry::flags\n" "\t= .org 2b+%c1\n" ".popsection" : : "i" (0), "i" (sizeof(struct bug_entry)))= ; } while (0); do { ({ asm volatile("132" ":\n\t" ".pushsection .discard.= unreachable\n\t" ".long " "132" "b - .\n\t" ".popsection\n\t"); }); __bui= ltin_unreachable(); } while (0); } while (0); >=20 >=20 > return -1; > } >=20 > Maybe it's because of definition of __compiletime_assert. >=20 > #ifdef __OPTIMIZE__ > # define __compiletime_assert(condition, msg, prefix, suffix) = \ > do { \ > extern void prefix ## suffix(void) __compiletime_error(msg)= ; \ > if (!(condition)) \ > prefix ## suffix(); \ > } while (0) > #else > # define __compiletime_assert(condition, msg, prefix, suffix) do { } wh= ile (0) > #endif >=20 >=20 > There can be an logical error or misunderstanding on my words. > If so, please tell me! >=20 > Thanks, > Hyeonggon >=20