Re: [PATCH] gpiolib: annotate struct acpi_gpio_mapping with __counted_by_ptr

[Linus Walleij]

On Mon, Sep 28, 2026 at 9:22 AM Bill Wendling <morbo@xxxxxxxxxx> wrote:
> On Sun, Sep 27, 2026 at 11:38 PM Bill Wendling <morbo@xxxxxxxxxx> wrote:
> >
> > The 'data' pointer field in 'struct acpi_gpio_mapping' is associated
> > with the 'size' field, which represents the number of elements of
> > type 'struct acpi_gpio_params' allocated for 'data'.
> >
> > To improve bounds checking via CONFIG_UBSAN_BOUNDS and
> > CONFIG_FORTIFY_SOURCE, annotate 'data' with the __counted_by_ptr
> > attribute.
> >
> > Analysis of allocation, assignment, and access points shows that the
> > pointer is never accessed before the count is set, which guarantees that
> > this annotation is safe and will not cause runtime panics or
> > false-positive bounds checks.
> >
> > Cc: codemender-patching+linux@xxxxxxxxxx
> > Assisted-by: LLM
> > Signed-off-by: Bill Wendling <morbo@xxxxxxxxxx>
> > ---
> >  include/linux/gpio/consumer.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
> > index fceeefd5f893..2b80cf7aa7e7 100644
> > --- a/include/linux/gpio/consumer.h
> > +++ b/include/linux/gpio/consumer.h
> > @@ -667,7 +667,7 @@ struct acpi_gpio_params {
> >
> >  struct acpi_gpio_mapping {
> >         const char *name;
> > -       const struct acpi_gpio_params *data;
> > +       const struct acpi_gpio_params *data __counted_by_ptr(size);
> >         unsigned int size;
> >
> >  /* Ignore IoRestriction field */
>
> There's a problem with 'drivers/firmware/efi/libstub/Makefile'. Clang
> needs a compiler flag to support the "__counted_by_ptr" attribute
> referencing a field *after* the pointer, like in this patch. However,
> the Makefile blasts the flag away for x86 platforms. Below is a hack
> that copies the part of the top-level Makefile that adds the flag. I
> don't think that's a good solution. The comment in the driver's
> Makefile says that the stub code executes before the kernel does,
> which I assume is why a lot of the flags are blown away... In any
> event, I'm not sure how best to address this.

But is this a problem with the current patch?

Does libefistub use <linux/gpio/consumer.h> in any way, shape
or form?

Yours,
Linus Walleij