Re: [PATCH] compiler_types: Allow opting out of __counted_by and __counted_by_ptr

[Bill Wendling]

On Mon, Oct 5, 2026 at 3:54 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>
> Hi Bill,
>
> On Mon, 5 Oct 2026, at 12:25, Bill Wendling wrote:
> > Code that runs outside the kernel proper, such as the EFI stub, gets
> > nothing out of the counted_by annotations: the bounds checks they feed
> > (FORTIFY_SOURCE, UBSAN_BOUNDS) are already disabled there.
> >
> > The annotations can also break the build. A __counted_by_ptr() that
> > names a member declared after the pointer needs Clang's
> > '-fexperimental-late-parse-attributes', which the top-level Makefile
> > adds to 'KBUILD_CFLAGS'. The x86 EFI stub builds its own cflags and does
> > not get that flag, so it fails as soon as such a struct is pulled in
> > through a common header.
> >
> > Overriding the macros from a Makefile doesn't work:
> > 'compiler_types.h' is pulled in with '-include', which is processed
> > after all -D/-U options, so it re-establishes the definitions. Follow
> > the '__NO_FORTIFY' precedent instead: let a build define
> > '__NO_COUNTED_BY' or '__NO_COUNTED_BY_PTR' to turn the corresponding
> > annotation into a no-op.  The two are kept separate but parallel so they
> > can be folded together once all supported compilers handle
> > '__counted_by' on pointers.
> >
>
> I'd prefer a single macro here - if there is ever a case where we need to
> turn off one but not the other, we can revisit.
>
> Otherwise, this looks good to me - thanks.

Hi Ard,

I wanted to do it this way because the two attributes rely upon
compiler versions, and this gives us more flexibility. Eventually,
there will be Only One(tm), once the minimal compiler version supports
both __counted_by and __counted_by_ptr.

But it's a small issue. I can resend with just the __NO_COUNTED_BY_PTR part.

-bw