Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1758660pxj; Sun, 16 May 2021 03:20:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzaCL9hFF70Lp9DAKh19JjvGUXU9/H/92PTBhgePxz7zN9tpHlmkxAG6QMuPi+j7ubPrvd8 X-Received: by 2002:a17:906:f42:: with SMTP id h2mr58118845ejj.317.1621160429986; Sun, 16 May 2021 03:20:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621160429; cv=none; d=google.com; s=arc-20160816; b=LVdnyCE/UhBkPe0myIV1crjTM4zjRsEdF/4MhYkXQA6dCZzzK1kWAls7Fl0xJXcxR5 n1QqttFzbeHr3AJ65xAvl/EkG1ojcElMOrjl6mnIKnwhdapV+KwYQ4EBxo3DGxy1JKcL l7grAk9/VEO0spE5ktzd7EnDBINKIbIal6uLDHW8PN6icA/G0nJsLrZter8zpcLrrzNm VsS1OeJbRoYxRhfaeGr7CTT6l5qx3sId8nFd8IBnQw44a5WWKmYTWezx4cMSFIDw5Iy8 mEu6CwIBqVcDgDMtrmHXBo4Dbp+V5Gmhmxw7rzUb9qkHb2pI0SsxK6ThBZg9k8mOkuvx bN+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Kld/T4tD7QhZRiqvKvoARJbmD47DL/ZGAeLVkkfzNJk=; b=swQ69lo321LBDQ9W+PHwhG9v9yU1QxLB19XN/OhdoXQTCYgmGZiPEItYiltQ2MjUgT DKq9mvuHipnpUgHmfI/OE0PZ/p4VkKapE9iJCPFlFhkcAhMuat9XN2ERpPMr64GXgcCx ziwCZqzkJC5oABNPl522q05NiFcUkWxOJoFeZMloCv5ZL6xPfwUEKZz+7a3oa8AKdAUr Y2tY8xxb21wSuptZm5uiV+lj4rS0PxlSeL6R0djWkiuQ8g2+vFGGn9ajX6gLm0l34ckt eSTLVRFeZ2C0O8pUKWTEwx2G6Xc2JlId9xaXO5zWzw07NHS7uXn9wXmRPPqEX5PfToQa HxAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KhZ5MoWo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q17si3252455edt.177.2021.05.16.03.20.07; Sun, 16 May 2021 03:20:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KhZ5MoWo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233459AbhEPGgK (ORCPT + 99 others); Sun, 16 May 2021 02:36:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:54776 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229840AbhEPGgJ (ORCPT ); Sun, 16 May 2021 02:36:09 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B07816100A; Sun, 16 May 2021 06:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621146895; bh=tOJvyDBi93XagwPx1i9XtsXpSm6miDwPi3jE4SjKmmY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KhZ5MoWo5uLP7ivqT7mfz2z9+6AQblT/RCUsxVJQfjLb0HGY8QymxsszvURVe2Ixo ibYuevSbFOgfIO1VYGOsjvtfna8ne2XHXqQZDsPcKV3ds1aX0Y8gAnGLn5frEWP6qT 6PUJOMGCGGkmyf07hkcHhvjJzyY6CGvG40Ip9fNvwg++DVnJ1DsZm4gaEE/iFMAvAB kzvdzpj2QEMnD8K6H6nPpLNX0QVVIjDrpPk+jazympQB5sN2kbALWZdRuQDA1h/d7W /d70KrpYnpf1SXm1eP8ss+bdUOjiHNj+/7e/gqEnsd44LlVIFKCgrUkc570JJFkYEN pXJebVP+DLqhg== Date: Sat, 15 May 2021 23:34:49 -0700 From: Nathan Chancellor To: Vlastimil Babka Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, akpm@linux-foundation.org, iamjoonsoo.kim@lge.com, rientjes@google.com, penberg@kernel.org, cl@linux.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, naresh.kamboju@linaro.org, clang-built-linux@googlegroups.com, linux-next@vger.kernel.org, ndesaulniers@google.com, lkft-triage@lists.linaro.org, sfr@canb.auug.org.au, arnd@arndb.de, Marco Elver Subject: Re: [PATCH v3] mm, slub: change run-time assertion in kmalloc_index() to compile-time Message-ID: References: <20210511173448.GA54466@hyeyoo> <20210515210950.GA52841@hyeyoo> <41c65455-a35b-3ad3-54f9-49ca7105bfa9@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41c65455-a35b-3ad3-54f9-49ca7105bfa9@suse.cz> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 15, 2021 at 11:24:25PM +0200, Vlastimil Babka wrote: > On 5/15/21 11:09 PM, Hyeonggon Yoo wrote: > > Hello Vlastimil, recently kbuild-all test bot reported compile error on > > clang 10.0.1, with defconfig. > > Hm yes, catching some compiler bug was something that was noted to be > possible to happen. > > > Nathan Chancellor wrote: > >> I think this happens because arch_prepare_optimized_kprobe() calls kzalloc() > >> with a size of MAX_OPTINSN_SIZE, which is > >> > >> #define MAX_OPTINSN_SIZE \ > >> (((unsigned long)optprobe_template_end - \ > >> (unsigned long)optprobe_template_entry) + \ > >> MAX_OPTIMIZED_LENGTH + JMP32_INSN_SIZE) > > > >> and the optprobe_template_{end,entry} are not evaluated as constants. > >> > >> I am not sure what the solution is. There seem to be a growing list of issues > >> with LLVM 10 that were fixed in LLVM 11, which might necessitate requiring > >> LLVM 11 and newer to build the kernel, given this affects a defconfig. > >> Cheers, > >> Nathan > > > > > > I think it's because kmalloc compiles successfully when size is constant, > > and kmalloc_index isn't. so I think compiler seems to be confused. > > > > currently if size is non-constant, kmalloc calls dummy function __kmalloc, > > which always returns NULL. > > That's a misunderstanding. __kmalloc() is not a dummy function, you > probably found only the header declaration. > > > so what about changing kmalloc to do compile-time assertion too, and track > > all callers that are calling kmalloc with non-constant argument. > > kmalloc() is expected to be called with both constant and non-constant > size. __builtin_constant_p() is used to determine which implementation > to use. One based on kmalloc_index(), other on __kmalloc(). > > It appears clang 10.0.1 is mistakenly evaluating __builtin_constant_p() > as true. Probably something to do with LTO, because MAX_OPTINSN_SIZE > seems it could be a "link-time constant". This happens with x86_64 defconfig so LTO is not involved. However, the explanation makes sense, given that the LLVM change I landed on changes the sparse conditional constant propagation pass, which I believe can influence how LLVM handles __builtin_constant_p(). > Maybe we could extend Marco Elver's followup patch that uses > BUILD_BUG_ON vs BUG() depending on size_is_constant parameter. It could > use BUG() also if the compiler is LLVM < 11 or something. What would be > the proper code for this condition? This should work I think: diff --git a/include/linux/slab.h b/include/linux/slab.h index 9d316aac0aba..1b653266f2aa 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -413,7 +413,7 @@ static __always_inline unsigned int __kmalloc_index(size_t size, if (size <= 16 * 1024 * 1024) return 24; if (size <= 32 * 1024 * 1024) return 25; - if (size_is_constant) + if ((IS_ENABLED(CONFIG_CC_IS_GCC) || CONFIG_CLANG_VERSION > 110000) && size_is_constant) BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); else BUG();