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=-1.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 77F50C4743F for ; Tue, 8 Jun 2021 17:05:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F1B3261285 for ; Tue, 8 Jun 2021 17:05:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1B3261285 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 247F66B006C; Tue, 8 Jun 2021 13:05:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F9196B006E; Tue, 8 Jun 2021 13:05:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 071946B0070; Tue, 8 Jun 2021 13:05:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0114.hostedemail.com [216.40.44.114]) by kanga.kvack.org (Postfix) with ESMTP id C4B436B006C for ; Tue, 8 Jun 2021 13:05:35 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5F49F82499A8 for ; Tue, 8 Jun 2021 17:05:35 +0000 (UTC) X-FDA: 78231183030.06.295CADF Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf06.hostedemail.com (Postfix) with ESMTP id 00E16C00CBE4 for ; Tue, 8 Jun 2021 17:05:31 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id g6-20020a17090adac6b029015d1a9a6f1aso2105231pjx.1 for ; Tue, 08 Jun 2021 10:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=orSTAp5x/mMQp98thmHsCHpCV8In3F9yntdLKF1qpx4=; b=lhfBUaUu3GaOLXiWl+J1snc/MIzURYklPNwL4QQzxOcMPCz6eUqqjDuk8w2WWgPswU hwg3GRvz6n5uCZS+Iu1FZzlTCigvdmFlXrvRLgsZ6WFk/qfrnJLcKGJheKFneMoi8gyn QTscmCmFYaOrDZtPf2sK0cdUJMdTkGQyJ5iAO3Z4fW0BF9MUWjleORn58ZGeCGgk3U8C AtVqvaxyNBXZcVpuptfF/eTBipCqYbiGC0ndxgHpdwwBX1EnQZ+iqDanlRJjjEJNxB86 55h0ZTwigQGaN3rHYtkxVmp3q2BZdO/hVr6TqXsJEGn/3o0iUncJEqJ0CTiVCmB9l96C WKRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=orSTAp5x/mMQp98thmHsCHpCV8In3F9yntdLKF1qpx4=; b=ENUXoPdSGPC7yztKIyEyanzlrIhxZLtJgwmEQ5gW3cHzWSnmNN6DGdGGQRFMsEXnfS rKleOr3IJLRmeRXRjvwJCjjCGQfpoipa0CtL8QJWN1TA8+1jngJQy0NSkTvL0uKVk0v8 mZs5kxDQ3+Rwn0O9K2JoVyvZtYAqjmK8b2ouHA+tmBDiOsOpzF7nOdRac6KtpKrZVlUK 6CzBYVd1kma+pOCPuAKNIekBi1Cpj20dnMh29kJFWnGppj5QKjOlRT6wUWnwIyp4M2Hx L4F1gHfhnzg+SXsWlyP78fYiVV6NUsoRToofYXOMnsZeM+X1qU1CNnIeczgmqK2d+wyr VJbA== X-Gm-Message-State: AOAM532KtE1bPLGMlaNnYFEZc3V61UyD5q4bF8OSquSSAXvYPHUG78Mq fVO03YH6ZX9RHruUmGKW5c8= X-Google-Smtp-Source: ABdhPJy9JGmr1NJhdSG84fDYRuVJk5P/Cv4IPr13LDayeh7HV41AV0NEiQU90n3QDDTa7OLHiyKUBQ== X-Received: by 2002:a17:90a:a393:: with SMTP id x19mr79823pjp.1.1623171933908; Tue, 08 Jun 2021 10:05:33 -0700 (PDT) Received: from hyeyoo ([183.99.11.150]) by smtp.gmail.com with ESMTPSA id c20sm2823210pjr.35.2021.06.08.10.05.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Jun 2021 10:05:33 -0700 (PDT) Date: Wed, 9 Jun 2021 02:05:28 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Vlastimil Babka Cc: kernel test robot , kbuild-all@lists.01.org, Linux Memory Management List , Andrew Morton 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: <20210608170528.GA28015@hyeyoo> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e1d48f2-409c-0a71-4d04-a907fe4183b8@suse.cz> Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=lhfBUaUu; spf=pass (imf06.hostedemail.com: domain of 42hyeyoo@gmail.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=42hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: sayia4enhub4iyxdir1oridj3kfdfufa X-Rspamd-Queue-Id: 00E16C00CBE4 X-Rspamd-Server: rspam06 X-HE-Tag: 1623171931-990608 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 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 wrote: > >> >> > >> >> But what exactly is the gcc problem here? > >> >> Did you have to reproduce it with specific gcc version and/or architecture? > >> >> > >> > > >> > 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. > >> > >> I'm involving my gcc colleagues, will report results... > > 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) Wow, AWESOME! How did your colleague find it? that was a big hint for me. when CONFIG_PROFILE_ALL_BRANCHES is not set, it doesn't make an error. > it might add too many instrumented if conditions to sustain the builtin-constant > tracking, which is not unlimited, or interact with optimizations in some other > corner case way. > I guess we could add IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) to the list of > conditions that excludes using BUILD_BUG_ON_MSG(). Well I wanted to understand how CONFIG_PROFILE_ALL_BRANCHES excludes BUILD_BUG_ON This is gcc's preprocessor output. So let's start from what CONFIG_PROFILE_ALL_BRANCHES does. #ifdef CONFIG_PROFILE_ALL_BRANCHES /* * "Define 'is'", Bill Clinton * "Define 'if'", Steven Rostedt */ #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) ) #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond)) #define __trace_if_value(cond) ({ \ static struct ftrace_branch_data \ __aligned(4) \ __section("_ftrace_branch") \ __if_trace = { \ .func = __func__, \ .file = __FILE__, \ .line = __LINE__, \ }; \ (cond) ? \ (__if_trace.miss_hit[1]++,1) : \ (__if_trace.miss_hit[0]++,0); \ }) #endif /* CONFIG_PROFILE_ALL_BRANCHES */ 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. then let's look at kmalloc_node, which is called by bpf_map_kmalloc_node. static inline __attribute__((__gnu_inline__)) __attribute__((__unused__)) __attribute__((no_instrument_function)) __attribute__((__always_inline__)) void *kmalloc_node(size_t size, gfp_t flags, int node){ if ( (__builtin_constant_p( !!(__builtin_constant_p(size) && size <= (1UL << ((11 + 12 - 1) <= 25 ? (11 + 12 - 1) : 25)))) ? (!!(__builtin_constant_p(size) && size <= (1UL << ((11 + 12 - 1) <= 25 ? (11 + 12 - 1) : 25)))) : ({ static struct ftrace_branch_data __attribute__ ((__aligned__(4))) __attribute__((__section__("_ftrace_branch"))) __if_trace = { .func = __func__, .file = "include/linux/slab.h", .line = 601, }; (!!(__builtin_constant_p(size) && size <= (1UL << ((11 + 12 - 1) <= 25 ? (11 + 12 - 1) : 25)))) ? (__if_trace.miss_hit[1]++,1) : (__if_trace.miss_hit[0]++,0); })) ) { unsigned int i = __kmalloc_index(size, true); It seems that gcc evaluates __builtin_constant_p( !!(builtin_constant_p(size) && size <= KMALLOC_MAX_CACHE_SIZE) ) as true. mm.. when the size passed to bpf_map_kmalloc_node is not constant, (__builtin_constant_p(size) && size <= KMALLOC_MAX_CACHE_SIZE) is false. then __builtin_constant_p(!!false) is true. So it calls kmalloc_index. what change should be made? just checking CONFIG_PROFILE_ALL_BRANCHES to kmalloc_index's if condition doesn't make sense, because kmalloc_node is not working as expected. 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 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. if ( (__builtin_constant_p(!!((0 || 110000 >= 110000) && size_is_constant)) ? (!!((0 || 110000 >= 110000) && size_is_constant)) : ({ static struct ftrace_branch_data __attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch"))) __if_trace = { .func = __func__, .file = "include/linux/slab.h", .line = 416, }; (!!((0 || 110000 >= 110000) && size_is_constant)) ? (__if_trace.miss_hit[1]++,1) : (__if_trace.miss_hit[0]++,0); })) ) do { extern void __compiletime_assert_131(void) ; // here - compiletime_assert_131 does NOTHING if ( (__builtin_constant_p(!!(!(!(1)))) ? (!!(!(!(1)))) : ({ static struct ftrace_branch_data __attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch"))) __if_trace = { .func = __func__, .file = "include/linux/slab.h", .line = 417, }; (!!(!(!(1)))) ? (__if_trace.miss_hit[1]++,1) : (__if_trace.miss_hit[0]++,0); })) ) __compiletime_assert_131(); } while (0); else do { do { } while(0); do { asm __inline volatile("1:\t" ".byte 0x0f, 0x0b" "\n" ".pushsection __bug_table,\"aw\"\n" "2:\t" ".long " "1b" " - 2b" "\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"); }); __builtin_unreachable(); } while (0); } while (0); return -1; } Maybe it's because of definition of __compiletime_assert. #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 { } while (0) #endif There can be an logical error or misunderstanding on my words. If so, please tell me! Thanks, Hyeonggon