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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 375D1C02192 for ; Wed, 5 Feb 2025 19:57:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB9BD280017; Wed, 5 Feb 2025 14:57:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A69FA280008; Wed, 5 Feb 2025 14:57:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95840280017; Wed, 5 Feb 2025 14:57:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 773BD280008 for ; Wed, 5 Feb 2025 14:57:43 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 05261B100E for ; Wed, 5 Feb 2025 19:57:42 +0000 (UTC) X-FDA: 83086951206.13.C1F23AD Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf05.hostedemail.com (Postfix) with ESMTP id 62486100002 for ; Wed, 5 Feb 2025 19:57:41 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZEmHbfVe; spf=pass (imf05.hostedemail.com: domain of nathan@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=nathan@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738785461; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zPcBdSvVSOW18f+yG/ej9xNWQmZLKPOwWKo/iveF3Kg=; b=xgaCbhkmoJgfidGuVbGm1q5oA/uEmpgf4xY2LwCP5Jn+3PtToef6hzfcKn7HZEZE0AlkVx eczLahtzqFAdwYnHhRBGI1VqUv5IbmrmjuozipZx5Pof20q6lZuRuG9xDmyAHVBYLD6/pc rdMTuiYnlmy+nDtNQNidfU6Q5gb4pKY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZEmHbfVe; spf=pass (imf05.hostedemail.com: domain of nathan@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=nathan@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738785461; a=rsa-sha256; cv=none; b=AoXoedUW0gA2/ulXfDLBkc9hFenskrba8GTebat8I1++F9xOEcEQZypG8HSFi3YiOvhk1H 6HFQpMVbIQigtzY5CELZcToEDE2LMPEUfJzGhiqhgrUwAUX0kB1lBaHTAKAf8CH5wKalRz mPeN0SBfTW9igNVzVaW2KPT7+QrhQds= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 88961A43765; Wed, 5 Feb 2025 19:55:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A885C4CED1; Wed, 5 Feb 2025 19:57:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738785460; bh=9HR7Vozs1dntR1ZRv7pelV/MJV5PwKSbAHdkRkpsW8M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZEmHbfVeQ4oI3uI7DDcbfR8Ww8Y8TP2ZEHWvarvsbimvoAayVMVoxJD8DIAzsL54b k83dJmcdU4WDlBrShfluuFB15+b7VV/IKYC53CxK7Fua0iH1bCXxRCsJF26nDAh1UC Yf82nQ/C9pQ2xJ9oI3zbkD6MXUlA668znt+u4wfz4paF/WJ7JeGJkCefC99074MQ/a Zdlz5RxGV+37uKOCeDzPKtQzlwu+UPciT+/Ti3uB5VzpjKR2ciiNEk9qFp3NKshFl2 KmIvUh/Iu5L2PTDSub1igt8YsnFh8PYAX1lLp292ZneJdPILruJeakOBzQfmd0glrG PlTi9A6EYty1Q== Date: Wed, 5 Feb 2025 12:57:35 -0700 From: Nathan Chancellor To: Kees Cook Cc: Suren Baghdasaryan , akpm@linux-foundation.org, kent.overstreet@linux.dev, ndesaulniers@google.com, morbo@google.com, justinstitt@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, kernel test robot Subject: Re: [PATCH 1/1] alloc_tag: work around clang-14 issue with __builtin_object_size() Message-ID: <20250205195735.GA1444602@ax162> References: <20250201200503.2532357-1-surenb@google.com> <202502051056.B910C691C@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202502051056.B910C691C@keescook> X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 62486100002 X-Stat-Signature: 5kmxcozw8bzbk4trjxamra6k5dysn3cy X-HE-Tag: 1738785461-898875 X-HE-Meta: U2FsdGVkX18Iphv8nK1JeFHwBTlkwEnkobrgWmRKvXQq9fBtEz9Gd9MA64dTDoqj9HlgmtOIdI2t9FQ7LRsQWh0vIzywjWgsFogtJuDOa/T/9y2IG1cZyJ05vQ+/eIh8iVP5/R6Wad2Y67AMIiecQgvnPilDeMK8fNXUb+3AkG8HRlktwUjOeu0GZ/2hUid1rHvzmiNyWiSKZCby+hOCR21TmeffIYikz0plUEG5happqOa69QmVcbeGoU3mjdmAlipMhuWyfRKwOlVdY153IfFVWW2FkObr7LtR9AWQDXGzPDxPb2nSd6LPDeC7R2IwD0XhyvwYLu0F55qtP3cbqjhXA/8tnzGP3dWQM08aNyR7zBU/BuxqYmUJGusGQU8SNe27zlf1bqCdWfqDdOo2V7yOS0OLSP48p2ibVfE+o2iOuE1uE9nwr/4vpirjKLj29iE4zKtHmvI8cbvkvODwpbJYf50ep2DRXtx/j1AR6LL7YhsSmUJtrct9mk3tHRZsyxeDyAFK//mAskI7fQg1nDjBxwdWDV8PkEKiI1LgMzaMdWQH/zscROUQqjx99xw6dWX5F4YbVhOabDy1oFrypA/4cKnjmLemtFWhpIWEXGlSyqp0LVAoeLkA/ADeRMaPeTCtEqYaPFRQnPcGp1eaoVcq6Qkzd4bHCobnl9qaWC0ugpMF5OuZUrO44q/LEJPuSdEgxSwGNs8xvrxBUkvTcz2TuB+yGwA2Su15Vf0U2K39qKo+O5iJoCB+Tb9xAsdnAY0z/N5GOM4DhNzoad3rbeL4/LyTlw5MPwVsMQymkpKbSQ6uw1DOgn7drbxR5di8JrkoM6FXt8GgLIRYmNruBYmw2B0D+0ATyVEC1h9P32PYhlObo69Omf6o7yn1z8Gu2nclJPY3Lww3TuqMh0Ya46O+jmZDbyvrBH8Tb1OdP9BExR1veKsM87LkN6mD8HUbEkppDd0itg9xpURC4CS A1al6CPG yrzt4T8GbS3Qgqh+OV+YclggHcBdOGZ2xbR3UqGJnhV+2jGqzQ1GWshts05b1SoQTiRUthYuFo9y+NiROJdvd0TbD2UNu4GVMQVRSIHNnwdvFCAYGs51zkr/SZjWR6Rc3RLOBeRNnIdAT1p9P9djxItjJSRPd9F8/e7QdE+ATxjWv7Ekf2bP6Hl+rG9Y7ZO9gCPRR6FHCssH8A3lTHS/FWKT85ZbsPFuO3HvkoT+qvjEcElqp3YzMlcEMJQddDfOQ1QGNb7XySiViOX+KJFPBVD9EtQVCcDtag/8mcTleydXSkJTHZ3nF+43jC6Vfdo9zcta3WutE2G96mrFw8dXgZX4ajAqdZwaaCxFzqU669/1wku6uRHcJRVaMvE8yDjAG5iIiKz15w5heGXk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Feb 05, 2025 at 11:18:35AM -0800, Kees Cook wrote: > On Sat, Feb 01, 2025 at 12:05:03PM -0800, Suren Baghdasaryan wrote: > > Additional condition in the allocation hooks causes Clang version 14 > > (tested on 14.0.6) to treat the allocated object size as unknown at > > compile-time (__builtin_object_size(obj, 1) returns -1) even though > > both branches of that condition yield the same result. Other versions > > of Clang (tested with 13.0.1, 15.0.7, 16.0.6 and 17.0.6) compile the > > same code without issues. Add build-time Clang version check which > > removes this condition and effectively restores the unconditional tag > > store/restore flow when compiled with clang-14. > > > > Fixes: 07438779313c ("alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled") > > Reported-by: kernel test robot > > Closes: https://lore.kernel.org/oe-kbuild-all/202501310832.kiAeOt2z-lkp@intel.com/ > > Signed-off-by: Suren Baghdasaryan > > --- > > include/linux/alloc_tag.h | 15 ++++++++++++++- > > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h > > index a946e0203e6d..df432c2c3483 100644 > > --- a/include/linux/alloc_tag.h > > +++ b/include/linux/alloc_tag.h > > @@ -222,10 +222,23 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {} > > > > #endif /* CONFIG_MEM_ALLOC_PROFILING */ > > > > +/* See https://lore.kernel.org/all/202501310832.kiAeOt2z-lkp@intel.com/ */ > > +#if defined(CONFIG_CC_IS_CLANG) && CONFIG_CLANG_VERSION >= 140000 && CONFIG_CLANG_VERSION < 150000 > > FWIW, this could just be "< 150000" -- < 14 doesn't warn because (as > Nathan mentioned to me today) it didn't support the build-time error > attribute, so it wouldn't have warned even if it did trip over it. > > > +static inline bool store_current_tag(void) > > +{ > > + return true; > > +} > > +#else > > +static inline bool store_current_tag(void) > > +{ > > + return mem_alloc_profiling_enabled(); > > +} > > +#endif > > + > > #define alloc_hooks_tag(_tag, _do_alloc) \ > > ({ \ > > typeof(_do_alloc) _res; \ > > - if (mem_alloc_profiling_enabled()) { \ > > + if (store_current_tag()) { \ > > struct alloc_tag * __maybe_unused _old; \ > > _old = alloc_tag_save(_tag); \ > > _res = _do_alloc; \ > > I think the work-around is fine, but I'm trying to dig into the root > cause here. > > As you found, it fails on the final strtomem_pad: > > strtomem_pad(key->u.kbd.press_str, press, '\0'); > strtomem_pad(key->u.kbd.repeat_str, repeat, '\0'); > strtomem_pad(key->u.kbd.release_str, release, '\0'); > > (but not the earlier calls??) The destinations are: > > char press_str[sizeof(void *) + sizeof(int)] __nonstring; > char repeat_str[sizeof(void *) + sizeof(int)] __nonstring; > char release_str[sizeof(void *) + sizeof(int)] __nonstring; > > Random thoughts include "this is the last array in the struct" which might > imply bad compiler behavior about its sizing via __builtin_object_size() > (i.e. trailing array must always be unknown size to deal with > fake flex arrays), but that wasn't fixed until Clang 16 (with > -fstrict-flex-arrays=3), so that it doesn't trip in Clang 15 is odd. I bisected the fix in LLVM 15 to https://github.com/llvm/llvm-project/commit/d8e0a6d5e9dd2311641f9a8a5d2bf90829951ddc, which certainly makes sense. Given the commit mentions phi nodes and folding means that maybe there is a branch that was not getting eliminated before this change? I have not really looked into the call chain here. > To Kent's comment[1], I believe I was using __builtin_object_size() here > because I have a knee-jerk aversion to sizeof() due to it blowing up on > flexible arrays, but that's not relevant here. ARRAY_SIZE() would work, > but only if type checking to "char *" succeeds, as Kent suggests. > > Let me see if making those changes survives testing... If that suggestion works, I would certainly prefer that to a compiler version workaround. Worst case, we could bump the minimum supported LLVM version over this but it does not seem serious enough to do so at the moment. Cheers, Nathan