From: Kees Cook <kees@kernel.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>,
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 <lkp@intel.com>
Subject: Re: [PATCH 1/1] alloc_tag: work around clang-14 issue with __builtin_object_size()
Date: Thu, 6 Feb 2025 10:13:21 -0800 [thread overview]
Message-ID: <202502061011.BD9611CEA@keescook> (raw)
In-Reply-To: <jdnvctbd4kfzgjy4s4wpd24zpv66zsn3cjgnsialjbnrl3oa4e@vexb7u4ku2tr>
On Wed, Feb 05, 2025 at 03:16:12PM -0500, Kent Overstreet wrote:
> 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:
> > 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?
Okay, here's my proposed fix, and confirmed that it solves the problem:
https://lore.kernel.org/lkml/20250206175216.work.225-kees@kernel.org
-Kees
--
Kees Cook
prev parent reply other threads:[~2025-02-06 18:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-01 20:05 [PATCH 1/1] alloc_tag: work around clang-14 issue with __builtin_object_size() Suren Baghdasaryan
2025-02-05 19:18 ` Kees Cook
2025-02-05 19:57 ` Nathan Chancellor
2025-02-05 20:16 ` Kent Overstreet
2025-02-05 21:28 ` Kees Cook
2025-02-06 18:13 ` Kees Cook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202502061011.BD9611CEA@keescook \
--to=kees@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=justinstitt@google.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=surenb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.