On Mon, Sep 28, 2026 at 9:22 AM Bill Wendling <[email protected]> wrote: > On Sun, Sep 27, 2026 at 11:38 PM Bill Wendling <[email protected]> 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: [email protected] > > Assisted-by: LLM > > Signed-off-by: Bill Wendling <[email protected]> > > --- > > 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
