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 5D190C02192 for ; Wed, 5 Feb 2025 19:18:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6965280004; Wed, 5 Feb 2025 14:18:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C1A15280003; Wed, 5 Feb 2025 14:18:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE0D5280004; Wed, 5 Feb 2025 14:18:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8A881280003 for ; Wed, 5 Feb 2025 14:18:38 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4492A1609D6 for ; Wed, 5 Feb 2025 19:18:38 +0000 (UTC) X-FDA: 83086852716.01.F437152 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf04.hostedemail.com (Postfix) with ESMTP id AC8FF4000C for ; Wed, 5 Feb 2025 19:18:36 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=b1y0PXmI; spf=pass (imf04.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@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=1738783116; 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=zZZPYtYo+5Tf+nbigrXrL/0t33dOfP7n2muNHIkEfO4=; b=76GKTpgblprjZnZk1JwgErdtY85o3seu7vr8+7npBRA8wni3JrmN0iFhBhsZmUp9qp1U6l tUHHJ9GQY661NgcJrrGWrury5RYC1x56jIYnpsahgGcipSZEegBB9MELvj9LG52iZK0rVU n3g7inzE7QbJ5JfH6QaXjgK4T5/GhrA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=b1y0PXmI; spf=pass (imf04.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738783116; a=rsa-sha256; cv=none; b=Rc7F+Sr81/zFccR9YQ6qZ+njSCtJHQnXKvJar0RN78e4SEDGGLwGKvkQkTY+oMm3AXv9sT WpCvHqfOLI9aRZ+BoAUAzvoN+nbHpO0ro5uWMgCm3lsAhTSN7EhJ8J+Ox7E5eVRa58gf/h pjKSz/fwrALC6T3R0g4qajLfhC/kS2M= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id CF9A0A439D1; Wed, 5 Feb 2025 19:16:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 836D3C4CED1; Wed, 5 Feb 2025 19:18:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738783115; bh=DVJod6AgATp1O+TTYUh9eYVwho2eGupKZZkC+Z7iPgQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=b1y0PXmIuWyOxpHrsAsMqBmea4NZ4kA9J/I51jW+4xaiNM+390lk/iXvzK2GCTshM HntQFKRRc97sl5xo31dz+/sCfM5BpuYKIQhlJ1WBRAWTUFpKzgm3wwhmJYesFgwxPb qNVRGwWbiaDEn6aD9lp+SI2j6ssHDaFxozfEXW8yKr8B3qL+Dh3f6GGdCiGqIHh1j+ GoxoVe54eXD2jVrHCdF/DLe4pWjFEtBvnYN5W/IjrSU0/78oW7RygOet0u/OlOHOrE sfN4YAlEbNcWWUAF3nIvS1pQZI/sMo6nI4VtsopErN+wjdrn6tPCyJ08lh7mdTnUmh XCO7Y0w9EPWDw== Date: Wed, 5 Feb 2025 11:18:35 -0800 From: Kees Cook To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, 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: <202502051056.B910C691C@keescook> References: <20250201200503.2532357-1-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250201200503.2532357-1-surenb@google.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AC8FF4000C X-Stat-Signature: 6e1r6sbruppmatqk3z6mgw7r5dbxeqtd X-Rspam-User: X-HE-Tag: 1738783116-583166 X-HE-Meta: U2FsdGVkX19rvBokpnqUZA8UYmfu2mamyehBhY+AGjTacgFQna9tOrSIxSMTGJiJfM//0hHZmexQbyuFD65GNrkYFoYRycPRHzkgDLrjXCH9HMdfSj0MkBm6/2wRy8JXosi68/cnnfO5i0O5bL/88WWZJootVyQR4KRyIwY4eD5YcpV+L57famflwhwn4vJTnnoDNVQKZVuIZFWFjEYuN+g96k1037dq+aDu8JcCKs4S8zZ6XN4EGRLRO4q4mdcYQY4FHpMYLRQwBXHqT9W4PWd5oMHmuHGxPSEee37mlipcvxUV9rgnmwjH9OsqWufomsyAuPCDJ7wGjewMZyI0rU1LVcYb3Z+HurARGApVrLwlrt/+jYTv9MzSFv4ZalreAOtBHqbOV/UoFiqRnwl1KYXgl1ttWckZngxdj5i6PPJNMFbv4aZ+SDXXqicvsj+wftIl8spWZPC0TQGFm6X8cpmQkt4/G7O+mO0+bEpIRSgDgaJRC6waUuN18OQrkncl80mJXtT7VJDjetR3pvyYr4CFjQobRQCfBVSKkk/aqlpCjVO+Ky2tVYFhz5vE52En46eAyTVvcr1wRugTvwtkdjrG7VJeKIyJK/wz86b35IKcpz7X4l83BeQozPdiO3oRPH9qlV7OjgOc3Cf7pRTjCsZFZgnQv6TW9SJdDJg5K8E/G1/3U7sXaFVziCPR4d7E2QGQ6c+VM9mG7uh6h9G19qoxENW3xdaKDEsklqims8RxEK34hRTReJ+zEBllfmudmqaCFn8eBosEjJordSuhy+N2Ne8rhi1KkRFzn05y+OGZ9HjSb4UhIrh4ug4sXo+Zrahn4YYM7/dotmOw0XVZHsARZUV460kAick+BUQVJUnM8YuNV8ZQ56NLgYyLi2hV6zL2hE8luMeUdI1+c70YMcaXs5eF2ouio0MpoA7H9mOh9iPGDMo6bxGFJ3/JmugwaM6hYzblsYFR7sBaS8m 93Z4r2FC mNNyoQGg/BrTuvweNSZYZ6xIDSgPuVucujAvlRqGNAwHOSO0K0/aorTzaLI4NY1obGxKiCxcgNloCmw7RVF6Cda3DTn6ZSYR5LgT5weFwTXtsqSDChRqTjmT+ThLeJOne795enqzN9qcGXJLlCtJ0EZlauejixeCPJyePz06T/zgpG5mmYWiGeyZB63SAz7hCsCOlh6a39K5QdWnxSJp9gEtN0+8WbuYkeU8A4cF1KgOxiAkMMb/+Va06RNzqXQPIqs2VQMcO8Y4t/uef40TWILPrFlDuZnRcTh996hMRkJXmsMtiyjyzqsvpHKbCbrG8LGYXq/U9pq5zf1XLNtDiC4k2Uzq3sE95uQNA+wCi12zLmc6fWBII0rW0dQ== 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 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. Let me see if making those changes survives testing... -Kees [1] https://lore.kernel.org/all/qbmazoiryyqygjk2x6bc7puqvmik7gyitzo3xnryzsodnrrjek@tahia33lvpli/ > > base-commit: 60c828cf80c07394762a1edfaff63bea55cc8e45 > -- > 2.48.1.362.g079036d154-goog > -- Kees Cook