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 94168C02192 for ; Wed, 5 Feb 2025 20:16:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 110CB280008; Wed, 5 Feb 2025 15:16:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C10A280013; Wed, 5 Feb 2025 15:16:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFC24280008; Wed, 5 Feb 2025 15:16:22 -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 D25D8280008 for ; Wed, 5 Feb 2025 15:16:22 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7E3A6C0B5C for ; Wed, 5 Feb 2025 20:16:22 +0000 (UTC) X-FDA: 83086998204.10.1A43EAD Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) by imf22.hostedemail.com (Postfix) with ESMTP id 95187C0010 for ; Wed, 5 Feb 2025 20:16:20 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Y1tn2txX; spf=pass (imf22.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738786580; 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=RY8iYnFHPWT+M4gWUF+5jQpYjoE7F10sz+0CtJqes/0=; b=Ro+A+Wr6nzVEQosR1o4WXOz6MUQuz+kxQ2zzYhzjGI4Fw7kfXX2l6jGwVPItAqIiZV+xtB jreqvYF0Cr15jwCIWVBWJu5kkfAkt1KzGNFcHmT72vAmDiH9M7+EsfyR2piio4kJrHsBsA SmGX5wkIudQYWNu/ZOI3933orMd8tDI= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Y1tn2txX; spf=pass (imf22.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738786580; a=rsa-sha256; cv=none; b=pdlXpQ2891kYrQSLr6tazsScethZ+JPX164v5eVusJKeb8wJJcs7rWBUWyfH9D1OJmZCWx YxPwfoqqze++WpGgUvgTwgVpdaYGdv2pVxmLvgc1wvvcabi5e+sKoDQhWgwkNS4T6YB7g5 B7R+oEWgXVOfcarWDPOgpsZi+NvWc6w= Date: Wed, 5 Feb 2025 15:16:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1738786578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RY8iYnFHPWT+M4gWUF+5jQpYjoE7F10sz+0CtJqes/0=; b=Y1tn2txXTxCsOtNDv0r1DlhJdu03Br3UKtW7gkxpadlUmBfXv/CEcwrzhj3yOclVOPE67S eH39BOiJFxGsztnWJ6ma/Rm30bTfxlNbPMNnYcMWCF+K/8bPXjCyoxDn5tHZwcawNv5E7B qBfTGH1TlFsUrWljZ/nbZRDMbRSrh5Y= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Kees Cook Cc: Suren Baghdasaryan , akpm@linux-foundation.org, nathan@kernel.org, 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: 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-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 95187C0010 X-Stat-Signature: hpnp3qm9jtjzhaumsdws3ma1mio1eqfs X-HE-Tag: 1738786580-765005 X-HE-Meta: U2FsdGVkX1/8WPIkZybbyAhmo0pKvYph4e5SKc8sEvNji4ImzwDxxsfrXDtX+jZOGaduWuovIIFgva0ugRnfXIsXGYcJEnz/ANjYAC7tzbF0JHQ5UQ6Hn60Xf+Czz8lw+a9C5U3+3mtWt0g+cLKR7EDvJ6OWZBPQVRasMT6ZFn1LZ5Y7yknYEgLO9ItaXBOnDp2gJY+3ankqvu9ccXy3jTkALxXb42G/BgT/knxX/PcrdY7fqaXJb8LO8GrT9m1NhSlLrm+1fhQI49HEGa1aLd72U/8pejRXj3LrfGdh7cpw6+AkuH+gqzaKDx1xbQ718irRd0eLsMZc3WeWpZDgqOtYAWUGY2vPogCa9KJJgKnTYm884Y+yLq0QQecNxugwbFWJLGR+9nlwozGf5aUZ0IHWrMXwwZyZ2D9j4sYkpPr8q3GJO5P5NTzPXB0AStxkMMYtT3z5LTaPwMLYEU72bwLLKXuSZnslz0aCaLEyASLVInU3lpNfw/fLb0wBAmP/1OQasVzMeSs3Fa7+QpqGfjWt/asCKFAdtcfdt51CBfTeiXUMqKAHfeWpBJ5uvygVSOrfHvesmLQCURWu1H49lgtO5c95aR/tmaQFaRiLqLHUgCZFZxC2i/CG702OcctEPNdqbutUKPDWpO7Hjm+2t4dKH+uRALmeKRJ1ijAMg7sNyEFNx6KPwH9MN+eDIZPfCv9b88KwkUHImpPCb99MuouGmz+ecNEF/nR2h/dMyf5LmP37+EGZLa7sGqybQzlsoZhxESC83m6dCk0MrRRQtqlMIoxxcrBO1QbN1VpWYreaF5gqDJT8c66o4GsZpheo0xbJP26ru2Vt3rmHqvx9oVa8Zw1keM3Frm5UelSMNj6Mxk3+TTFjWpuATKfa/Jo6W+JTMWr/a/pPMC/qBRmUgdXgUbm/FsKUkSwPaocFBLCkCvK4/HyRBWuDRaauFcDYc2+5Mr0lFv5E99CWtz7 bfUUTdVM Bmsb48hIybIATU+yvzAlAHPU0afjo3ggkz5bBEG//4j9XJg8thnW6c09p9KGRKizoJabzVXKaNpLrbhG/kXTjUGpIETDP9HHnhvPwX8eudQIgZI16NK1E7koc3hiBnQzH571Sw7i2tVClSJHEI1X8nu4HAYFjCRbRVxSMUvbW62XEzuCrDnaHT3050jLWxM7FnRhV1t6xhKxhOuXi82RIM5jvF1OEhzjfsw4ly6ayNwhA3LcjnyIbpAW/+HEkZZ0uJnnjTsKG8UdD0e0RM6A7DK4Df7qt2A+FHILYcSKM3WR+WUc= 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: 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. > > 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. Yeah, that rational for __builtin_object_size() makes sense - although it's not what the gcc docs say, those talk about getting the size from an attribute on the allocation function (!). ARRAY_SIZE() is sizeof() underneath, just used creatively to guarantee that the input is an array - although that property is probably what we want here, since strtomem_pad() really only makes sense on static or flex-arrays, no?