All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mert Seftali" <mertsftl@gmail.com>
Cc: lee@kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH v3] leds: pwm: Annotate leds[] with __counted_by()
Date: Fri, 10 Jul 2026 07:11:31 +0000	[thread overview]
Message-ID: <20260710071132.2AAB91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260710070141.37214-1-mertsftl@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The refactoring to use pointer arithmetic (led_data++) bypasses the newly added __counted_by() bounds checking.
--

--- Patch [1]: [PATCH v3] leds: pwm: Annotate leds[] with __counted_by() ---
commit c418c024dbd5055ff67d14fc9a244c4d09795169
Author: Mert Seftali <mertsftl@gmail.com>

leds: pwm: Annotate leds[] with __counted_by()

Adds the __counted_by() attribute to the flexible array member leds[] in
struct led_pwm_priv for bounds checking. To avoid UBSAN triggers during
initialization, the code is refactored to pass a led_pwm_data pointer into
led_pwm_add() instead of indexing the array directly.

> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -81,10 +81,9 @@ static int led_pwm_default_brightness_get(struct fwnode_handle *fwnode,
>  }
>  
>  __attribute__((nonnull))
> -static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> +static int led_pwm_add(struct device *dev, struct led_pwm_data *led_data,
>  		       struct led_pwm *led, struct fwnode_handle *fwnode)
>  {
> -	struct led_pwm_data *led_data = &priv->leds[priv->num_leds];

[ ... ]

>  static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
>  {
> +	struct led_pwm_data *led_data = priv->leds;
>  	struct led_pwm led;
>  	int ret;
>  
> @@ -193,7 +192,7 @@ static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
>  
>  		led.default_state = led_init_default_state_get(fwnode);
>  
> -		ret = led_pwm_add(dev, priv, &led, fwnode);
> +		ret = led_pwm_add(dev, led_data++, &led, fwnode);

[Severity: Medium]
By decaying the flexible array to a pointer and using pointer arithmetic
(led_data++), doesn't the compiler lose the context needed to enforce the
__counted_by bounds check?

Compilers and sanitizers typically enforce __counted_by mitigations during
array subscripting operations like priv->leds[i]. Because priv->leds is
decayed into a standalone pointer and passed to led_pwm_add(), all bounds
information relative to priv->num_leds appears to be lost.

Will the primary objective of adding __counted_by be neutralized by passing
the element as a bare pointer here rather than using an index?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710070141.37214-1-mertsftl@gmail.com?part=1

  reply	other threads:[~2026-07-10  7:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10  7:01 [PATCH v3] leds: pwm: Annotate leds[] with __counted_by() Mert Seftali
2026-07-10  7:11 ` sashiko-bot [this message]
2026-07-10  8:53   ` Mert Seftali

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=20260710071132.2AAB91F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=mertsftl@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.