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 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 5D3E1C47094 for ; Thu, 10 Jun 2021 05:17:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D96AC613DE for ; Thu, 10 Jun 2021 05:17:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D96AC613DE 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 D7DB66B0036; Thu, 10 Jun 2021 01:17:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB8956B006E; Thu, 10 Jun 2021 01:17:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE37A6B0070; Thu, 10 Jun 2021 01:17:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 723256B0036 for ; Thu, 10 Jun 2021 01:17:10 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0B6446123 for ; Thu, 10 Jun 2021 05:17:10 +0000 (UTC) X-FDA: 78236655420.35.8E4DC86 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf01.hostedemail.com (Postfix) with ESMTP id DA1FB5001700 for ; Thu, 10 Jun 2021 05:17:04 +0000 (UTC) Received: by mail-pl1-f181.google.com with SMTP id b12so343253plg.11 for ; Wed, 09 Jun 2021 22:17:09 -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=XZ92z7bq1UQiO9/mNxAISVvAO/Ne15XbPilmjNitHAs=; b=FnTc5j/DMqXMlGdHm08yQ2z1N7TL11dJp9nU4gKs1deqKes5vkRk9+guNo1DSbs2xa Bq7s02KqSfT/pGmtKal+cnQyE1CiswiofbyLZ+xg8N3OhSP3w+VEIeY5e5/tTaYa7K1S Z0VjasbpwkKTBaQsck951qebzUbnFGzde8nw79uDB7N3yFpz9BQpaY9Kv2DVqRRR5F/I coBHYVSW6suThcs84D1yJdCJycuDWd0tRFtnlnsXqDCd680/gfwWJSPI/UOotNVWWqY8 m1/EJ24UcRnH0upGMbUfAzavoYdBF79riyGEmbiENrKw+U3MKDoK2mF8fRpeCGb3xDYu S0KA== 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=XZ92z7bq1UQiO9/mNxAISVvAO/Ne15XbPilmjNitHAs=; b=W9zOnSjk36Ad9SH8jpm+n4OYqdy+NdzcBDWHdZ0hg89JAWyE7yGhG3pdsEwofp7md9 54Kkm/RZDSGeGaZ+ezDO3mJ0+PtomM3KP2h/alpIYLIBf2eWbi/7eODqbI2JaUQTlDYv UrjzMSneVPff9gPAUXc8JqOp1J1Dmd9etu1XBDtWQ9OTFkfF9jkA047VsomS1SOf6faT jlFPiXPrqvIEt2gFe/Qpd07GHTtiX29F2bBicGZn/0kmLXN0PVzoVtjy5fj4/xRT6y5g tKABTB25TMGZm8RHl4XRgb2TwI40P3GgcmzTCR0pw0ker6++wL1j5bDjPR7yvUxQmLN1 KuwQ== X-Gm-Message-State: AOAM531t1QKamr40bpmQ98pygXFAlWmtmzs2c8dhddAMAH/grVxMuCnl mLj4CGmij+EjKcPW8fSzYrY= X-Google-Smtp-Source: ABdhPJwsGmU14AEeG/ntdanr7ISaYBMcWhwpIJCKNcM6MSPgOChRdOS3Z7P8G/HFRhBhBwzsWTZJOw== X-Received: by 2002:a17:903:248e:b029:101:fa49:3f96 with SMTP id p14-20020a170903248eb0290101fa493f96mr3271878plw.16.1623302228589; Wed, 09 Jun 2021 22:17:08 -0700 (PDT) Received: from hyeyoo ([1.211.102.101]) by smtp.gmail.com with ESMTPSA id d15sm6429848pjr.47.2021.06.09.22.17.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Jun 2021 22:17:08 -0700 (PDT) Date: Thu, 10 Jun 2021 14:17:02 +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: Some logical errors on my words, but I still wonder... Message-ID: <20210610051702.GA5630@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> <20210608170528.GA28015@hyeyoo> <2d2d792e-e189-99a4-36cb-f1473a4df9ad@suse.cz> <20210608184501.GA5505@hyeyoo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210608184501.GA5505@hyeyoo> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DA1FB5001700 X-Stat-Signature: 4uz9qmox155xhx97qh6xq9pfwg6riiqm Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b="FnTc5j/D"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of 42hyeyoo@gmail.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=42hyeyoo@gmail.com X-HE-Tag: 1623302224-954500 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 Wed, Jun 09, 2021 at 03:45:01AM +0900, Hyeonggon Yoo wrote: > static __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); > > > they are so ugly but the point is: > > > > 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. > > > There were some logical errors on my words. I still think the compiler evaluate it as true, but that is not reason why kmalloc_node calls __kmalloc_index for non-constant size. I wonder why kmalloc_node called __kmalloc_index(size, size_is_constant=true) for non-constant size. Thanks, Hyeonggon > > > 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. > some evidence to add: > > there are 4 calls of bpf_map_kmalloc_node. > if you comment out two calls of bpf_map_kmalloc_node with non-constant > (in line 168, 508), it doesn't make an error. So I thought > it was problem when non-constant size was passed. > > And if "kmalloc_index makes problem with non-constant size" is > true, then it is caller's fault because it is not allowed (except > in __kmalloc_index) > > kmalloc_node shouldn't call kmalloc_index if the size was not > constant. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1355089672210566274==" MIME-Version: 1.0 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: kbuild-all@lists.01.org Subject: Some logical errors on my words, but I still wonder... Date: Thu, 10 Jun 2021 14:17:02 +0900 Message-ID: <20210610051702.GA5630@hyeyoo> In-Reply-To: <20210608184501.GA5505@hyeyoo> List-Id: --===============1355089672210566274== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Jun 09, 2021 at 03:45:01AM +0900, Hyeonggon Yoo wrote: > static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int n= ode) > { > = > 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)))) = > : ({ static struct ftrace_branch_data __attribute__((__aligned__(4))) = __attribute__((__section__("_ftrace_branch"))) __if_trace =3D { .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)))) ? (__if_trace.miss_hit[1]++,1) : (__if_trace.miss_hit[0]++,0); }= )) ) > { > unsigned int i =3D __kmalloc_index(size, true); > = > = > they are so ugly but the point is: > = > > > It seems that gcc evaluates > > > = > > > __builtin_constant_p( > > > !!(builtin_constant_p(size) > > > && size <=3D KMALLOC_MAX_CACHE_SIZE) > > > ) > > > as true. > > > > > > mm.. when the size passed to bpf_map_kmalloc_node is not constant, > > > (__builtin_constant_p(size) && size <=3D KMALLOC_MAX_CACHE_SIZE) is f= alse. > > > then __builtin_constant_p(!!false) is true. So it calls kmalloc_index. > > > There were some logical errors on my words. I still think the compiler evaluate it as true, but that is not reason why kmalloc_node calls __kmalloc_index for non-constant size. I wonder why kmalloc_node called __kmalloc_index(size, size_is_constant=3Dt= rue) for non-constant size. Thanks, Hyeonggon > > > what change should be made? > > > just checking CONFIG_PROFILE_ALL_BRANCHES to kmalloc_index's if condi= tion > > > doesn't make sense, because kmalloc_node is not working as expected. > some evidence to add: > = > there are 4 calls of bpf_map_kmalloc_node. > if you comment out two calls of bpf_map_kmalloc_node with non-constant > (in line 168, 508), it doesn't make an error. So I thought > it was problem when non-constant size was passed. > = > And if "kmalloc_index makes problem with non-constant size" is > true, then it is caller's fault because it is not allowed (except > in __kmalloc_index) > = > kmalloc_node shouldn't call kmalloc_index if the size was not > constant. --===============1355089672210566274==--