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=-11.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,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS 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 CBBABC47082 for ; Mon, 7 Jun 2021 12:26:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3E0E361246 for ; Mon, 7 Jun 2021 12:26:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E0E361246 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 912AF6B006C; Mon, 7 Jun 2021 08:25:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C31D6B006E; Mon, 7 Jun 2021 08:25:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73CEF6B0070; Mon, 7 Jun 2021 08:25:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id 43F236B006C for ; Mon, 7 Jun 2021 08:25:59 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D31E2180AD802 for ; Mon, 7 Jun 2021 12:25:58 +0000 (UTC) X-FDA: 78226849596.11.9A70526 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by imf28.hostedemail.com (Postfix) with ESMTP id 47F102001086 for ; Mon, 7 Jun 2021 12:25:56 +0000 (UTC) Received: by mail-pg1-f176.google.com with SMTP id y12so1845679pgk.6 for ; Mon, 07 Jun 2021 05:25:58 -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=2+a6S9c6qkKxDfPhAgEeH5RUI/s3MvxFZhBLytZ4h34=; b=X7/3NavrHaorhVT5waJErlM1xOmKTrpiDwnSXNOVQp7/W1D/LToQn4dRS7K/ARpa2x VfE6Yk9iAPR/jltyfikROm2tzWeI8PfsQxMnzJjrHam5WRGEtYx5CGu69kw8hOILTX4h MPDjtpmyvgmiNYqSYH7JSwl6Ew00qmOt/gaMSOYNgX64pEf7Gbcd08Rpzmb7SnbROhFt wqGHfbIPQ9N06WfcesaE7Tn6O8eFvzvwQrqP5aI3fD7oh1qp++S2pZWT/KgaUPdQ54zL gNfXClCNTgo7V29yCNEEck3wPJaKJ9TUovbs8scGxlESk5lbxKdejebhrFlutvobK8OF zICQ== 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=2+a6S9c6qkKxDfPhAgEeH5RUI/s3MvxFZhBLytZ4h34=; b=C51d4PrFWeaKGafMoflBpmZ+Zj/1L4abpVW0d+JGUv6kNTfQdeoMfRibQmgDc4Axd8 /lPLBI9EZHgL5FQHQAH4Gov8rknZJaf8PT+fNuuP6JC/O6RxCeHP+eTboe7t8Lvx86Vc ubR81PM1I8UGnuHcYd2XuZt4QuuLA9yJdcC16YIhPgFlvBAVb4U/BfYej10JbURoDssX s+bmjxFBez++wrJyJ/1d/7KgOExhQmXOBXANhNwrtSQHz3r0v8pfwRuyDQ4BhCTMxge4 RnZA3wH5F/wKIc9WEbIofA47KcrouqB5hn/w63NXJnvbAqsSKwchqmCjmi/EA1u/M12+ 7r0g== X-Gm-Message-State: AOAM533nMRdVvu5apg2VuzxRuAHP9WkXtsIQqUpNqOKiz1cwJ3f80OPq 9gROsxzKWbLeNxgdENjherU= X-Google-Smtp-Source: ABdhPJxavnMFPF+vF6Q0BvlQJOdllabtTOIQZYBd52XPL0W5LVaqrv+yVCPzgC6xLpzwAGaRRjM32Q== X-Received: by 2002:a63:3603:: with SMTP id d3mr14282159pga.346.1623068757338; Mon, 07 Jun 2021 05:25:57 -0700 (PDT) Received: from hyeyoo ([39.7.58.180]) by smtp.gmail.com with ESMTPSA id 23sm7399858pjw.28.2021.06.07.05.25.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jun 2021 05:25:57 -0700 (PDT) Date: Mon, 7 Jun 2021 21:25:50 +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: <20210607122550.GA752464@hyeyoo> References: <202106051442.G1VJubTz-lkp@intel.com> <20210606110839.GA13828@hyeyoo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 47F102001086 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b="X7/3Navr"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 42hyeyoo@gmail.com designates 209.85.215.176 as permitted sender) smtp.mailfrom=42hyeyoo@gmail.com X-Stat-Signature: pepp8ikwi8cncfxwyc74ypsxyz97p5fq X-HE-Tag: 1623068756-953374 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 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: > >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > >> head: ccc252d2e818f6a479441119ad453c3ce7c7c461 > >> commit: a7ba988ff9de37f0961b4bf96d17aca73d0d2e25 [7012/7430] mm, slub: change run-time assertion in kmalloc_index() to compile-time > >> config: parisc-randconfig-r014-20210604 (attached as .config) > >> compiler: hppa-linux-gcc (GCC) 9.3.0 > >> reproduce (this is a W=1 build): > >> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > >> chmod +x ~/bin/make.cross > >> # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a7ba988ff9de37f0961b4bf96d17aca73d0d2e25 > >> git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > >> git fetch --no-tags linux-next master > >> git checkout a7ba988ff9de37f0961b4bf96d17aca73d0d2e25 > >> # save the attached .config to linux build tree > >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc > >> > >> If you fix the issue, kindly add following tag as appropriate > >> Reported-by: kernel test robot > >> > >> All errors (new ones prefixed by >>): > >> 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 '__compiletime_assert_183' declared with attribute error: unexpected size in kmalloc_index() > >> 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 '_compiletime_assert' > >> 328 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > >> | ^~~~~~~~~~~~~~~~~~~ > >> include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_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()"); > >> | ^~~~~~~~~~~~~~~~ > > > > Reproduce with attached config, and read the code. > > It has no problem in clang (clang-10/clang-11). it is problem with gcc. > > 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 found the error was in kernel/bpf/local_storage.c and I copied the bot's config in linux-next (20210607), and just entered all new config. running 'make kernel/bpf/local_storage.o CC=gcc' can reproduce the error. the bot says it is error with parisc, but I was able to reproduce it in my x86 machine. I tested on gcc-9.3.0 and gcc-10.2.0 both makes an error, and clang 10.0.1, clang 11.0.0 didn't make an error. > > I found two ways to solve the error (maybe there would be better > > solution) Any thoughts or opinions? > > > > > > First ways is to change condition of kmalloc_index macro. > > > > diff --git a/include/linux/slab.h b/include/linux/slab.h > > index 70e46db766ca..be2c900cba4b 100644 > > --- a/include/linux/slab.h > > +++ b/include/linux/slab.h > > @@ -397,7 +397,7 @@ static __always_inline unsigned int __kmalloc_index(size_t size, > > /* Will never be reached. Needed because the compiler may complain */ > > return -1; > > } > > -#define kmalloc_index(s) __kmalloc_index(s, true) > > +#define kmalloc_index(s) __kmalloc_index(s, __builtin_constant_p(s) && true) > > I wonder how this extra guard can possibly matter? > > bpf_map_kmalloc_node() > kmalloc_node() > if (__builtin_constant_p(size) ...) > unsigned int i = kmalloc_index(size); > > We shouldn't be even reaching kmalloc_index() unless __builtin_constant_p(size) > is already true. Yes, I knew that when I wrote the code. That totally doesn't make sense. why __builtin_constant_p(size) was true in kmalloc_node, and false in the evalaution (__builtin_constant_p(s) && true)? but it actually solves the error. At this point, I thought gcc was doing something wrong.... Well, I know we need more evidence to conclude gcc is wrong. (Or we made wrong code that makes compiler confusing.) I want to hear you and some other people's opinion. > > #endif /* !CONFIG_SLOB */ > > > > void *__kmalloc(size_t size, gfp_t flags) __assume_kmalloc_alignment __malloc; > > > > > > Second way is making bpf_map_kmalloc_node always inline. > > If bpf_map_kmalloc_node() is not being compiled as inline, how can it possibly > evaluate __builtin_constant_p(size) as true when processing the inlined > kmalloc_node()? As I said above - it doesn't make sense, but gcc is acting differently on __inline and inline, in bpf_map_kmalloc_node function. just making bpf_map_kmalloc_node always solves the error, but I have no clue WHY... anyway, in summary: - the diff I sent should not make sense, but it works for gcc. - So I think gcc is doing something wrong (but more evidence needed) I can be missing something. So If I said something wrong, or if you can't reproduce the error, please tell me! Thanks, Hyeonggon Yoo > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > index 02b02cb29ce2..09379d705349 100644 > > --- a/include/linux/bpf.h > > +++ b/include/linux/bpf.h > > @@ -1312,7 +1312,7 @@ void *bpf_map_kzalloc(const struct bpf_map *map, size_t size, gfp_t flags); > > void __percpu *bpf_map_alloc_percpu(const struct bpf_map *map, size_t size, > > size_t align, gfp_t flags); > > #else > > -static inline void * > > +static __always_inline void * > > bpf_map_kmalloc_node(const struct bpf_map *map, size_t size, gfp_t flags, > > int node) > > { > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============8609511242975861127==" MIME-Version: 1.0 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: kbuild-all@lists.01.org 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() Date: Mon, 07 Jun 2021 21:25:50 +0900 Message-ID: <20210607122550.GA752464@hyeyoo> In-Reply-To: List-Id: --===============8609511242975861127== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: > >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-nex= t.git master > >> head: ccc252d2e818f6a479441119ad453c3ce7c7c461 > >> commit: a7ba988ff9de37f0961b4bf96d17aca73d0d2e25 [7012/7430] mm, slub:= change run-time assertion in kmalloc_index() to compile-time > >> config: parisc-randconfig-r014-20210604 (attached as .config) > >> compiler: hppa-linux-gcc (GCC) 9.3.0 > >> reproduce (this is a W=3D1 build): > >> wget https://raw.githubusercontent.com/intel/lkp-tests/master/= sbin/make.cross -O ~/bin/make.cross > >> chmod +x ~/bin/make.cross > >> # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n= ext.git/commit/?id=3Da7ba988ff9de37f0961b4bf96d17aca73d0d2e25 > >> git remote add linux-next https://git.kernel.org/pub/scm/linux= /kernel/git/next/linux-next.git > >> git fetch --no-tags linux-next master > >> git checkout a7ba988ff9de37f0961b4bf96d17aca73d0d2e25 > >> # save the attached .config to linux build tree > >> COMPILER_INSTALL_PATH=3D$HOME/0day COMPILER=3Dgcc-9.3.0 make.c= ross ARCH=3Dparisc = > >> = > >> If you fix the issue, kindly add following tag as appropriate > >> Reported-by: kernel test robot > >> = > >> All errors (new ones prefixed by >>): > >> 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/li= nux/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_ind= ex() > >> 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 '= _compiletime_assert' > >> 328 | _compiletime_assert(condition, msg, __compiletime_assert_,= __COUNTER__) > >> | ^~~~~~~~~~~~~~~~~~~ > >> include/linux/build_bug.h:39:37: note: in expansion of macro 'compi= letime_assert' > >> 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(co= nd), 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()"); > >> | ^~~~~~~~~~~~~~~~ > > = > > Reproduce with attached config, and read the code. > > It has no problem in clang (clang-10/clang-11). it is problem with gcc. > = > But what exactly is the gcc problem here? > Did you have to reproduce it with specific gcc version and/or architectur= e? > = 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 found the error was in kernel/bpf/local_storage.c and I copied the bot's config in linux-next (20210607), and just entered al= l new config. running 'make kernel/bpf/local_storage.o CC=3Dgcc' can reproduce the error. the bot says it is error with parisc, but I was able to reproduce it in my x86 machine. I tested on gcc-9.3.0 and gcc-10.2.0 both makes an error, and clang 10.0.1, clang 11.0.0 didn't make an error. > > I found two ways to solve the error (maybe there would be better > > solution) Any thoughts or opinions? > > = > > = > > First ways is to change condition of kmalloc_index macro. > > = > > diff --git a/include/linux/slab.h b/include/linux/slab.h > > index 70e46db766ca..be2c900cba4b 100644 > > --- a/include/linux/slab.h > > +++ b/include/linux/slab.h > > @@ -397,7 +397,7 @@ static __always_inline unsigned int __kmalloc_index= (size_t size, > > /* Will never be reached. Needed because the compiler may compl= ain */ > > return -1; > > } > > -#define kmalloc_index(s) __kmalloc_index(s, true) > > +#define kmalloc_index(s) __kmalloc_index(s, __builtin_constant_p(s) &&= true) > = > I wonder how this extra guard can possibly matter? > > bpf_map_kmalloc_node() > kmalloc_node() > if (__builtin_constant_p(size) ...) > unsigned int i =3D kmalloc_index(size); > = > We shouldn't be even reaching kmalloc_index() unless __builtin_constant_p= (size) > is already true. Yes, I knew that when I wrote the code. That totally doesn't make sense. why __builtin_constant_p(size) was true in kmalloc_node, and false in the evalaution (__builtin_constant_p(s) && true)? but it actually solves the error. At this point, I thought gcc was doing something wrong.... Well, I know we need more evidence to conclude gcc is wrong. (Or we made wrong code that makes compiler confusing.) I want to hear you and some other people's opinion. > > #endif /* !CONFIG_SLOB */ > > = > > void *__kmalloc(size_t size, gfp_t flags) __assume_kmalloc_alignment _= _malloc; > > = > > = > > Second way is making bpf_map_kmalloc_node always inline. > = > If bpf_map_kmalloc_node() is not being compiled as inline, how can it pos= sibly > evaluate __builtin_constant_p(size) as true when processing the inlined > kmalloc_node()? As I said above - it doesn't make sense, but gcc is acting differently on __inline and inline, in bpf_map_kmalloc_node function. just making bpf_map_kmalloc_node always solves the error, but I have no clue WHY... anyway, in summary: - the diff I sent should not make sense, but it works for gcc. - So I think gcc is doing something wrong (but more evidence needed) I can be missing something. So If I said something wrong, or if you can't reproduce the error, please tell me! Thanks, Hyeonggon Yoo > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > > index 02b02cb29ce2..09379d705349 100644 > > --- a/include/linux/bpf.h > > +++ b/include/linux/bpf.h > > @@ -1312,7 +1312,7 @@ void *bpf_map_kzalloc(const struct bpf_map *map, = size_t size, gfp_t flags); > > void __percpu *bpf_map_alloc_percpu(const struct bpf_map *map, size_t = size, > > size_t align, gfp_t flags); > > #else > > -static inline void * > > +static __always_inline void * > > bpf_map_kmalloc_node(const struct bpf_map *map, size_t size, gfp_t fla= gs, > > int node) > > { > > = >=20 --===============8609511242975861127==--