From: sashiko-bot@kernel.org
To: Arunachalam <arun07172003@gmail.com>
Cc: lee@kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH v2 3/4] leds: menf21bmc: convert to dev_err_probe()
Date: Thu, 23 Jul 2026 16:56:50 +0000 [thread overview]
Message-ID: <20260723165650.D619D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260723164612.3146-3-arun07172003@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Low] The commit message description is not capitalized.
Pre-existing issues:
- [Critical] The driver manages LED instances using a shared static global array `leds`, causing kernel list corruption and use-after-free crashes if multiple devices probe or unbind.
- [High] The LED brightness control callback `menf21bmc_led_set` sleeps but is incorrectly assigned to the non-blocking `brightness_set` hook.
--
--- Patch [3]: [PATCH v2 3/4] leds: menf21bmc: convert to dev_err_probe() ---
commit 256232e59da7fa918a47e5b2a0fabb6d2df03b37
Author: Arunachalam <arun07172003@gmail.com>
leds: menf21bmc: convert to dev_err_probe()
Replace open-coded dev_err() + return pattern with dev_err_probe(),
which also handles -EPROBE_DEFER correctly.
> leds: menf21bmc: convert to dev_err_probe()
[Severity: Low]
This isn't a bug introduced by this patch, but subsystem guidelines mandate
that the description after the subsystem prefix must be capitalized for LED
drivers. Should this be "Convert to dev_err_probe()"?
> diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
> index 6b1b471606026..a7e4db4879d81 100644
> --- a/drivers/leds/leds-menf21bmc.c
> +++ b/drivers/leds/leds-menf21bmc.c
> @@ -84,10 +84,8 @@ static int menf21bmc_led_probe(struct platform_device *pdev)
> leds[i].cdev.brightness_set = menf21bmc_led_set;
[Severity: High]
This is a pre-existing issue, but does assigning menf21bmc_led_set to the
non-blocking brightness_set hook risk a scheduling while atomic panic?
If the LED is set to blink via sysfs, led_timer_function executes in atomic
softirq context and calls this brightness_set callback. However,
menf21bmc_led_set() takes a mutex and performs I2C transactions which can
sleep.
Should this be assigned to brightness_set_blocking instead?
> leds[i].i2c_client = i2c_client;
> ret = devm_led_classdev_register(&pdev->dev, &leds[i].cdev);
[Severity: Critical]
This is a pre-existing issue, but does registering a globally shared static
cdev object risk linked list corruption?
The driver manages LED instances using a single static global array (leds).
If multiple devices are probed or if a user unbinds and rebinds the device,
devm_led_classdev_register() will be called on the same leds[i].cdev
structure.
The LED core calls list_add_tail() on a node already in a linked list, which
corrupts the global leds_list.
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to register LED device\n");
> - return ret;
> - }
> + if (ret < 0)
> + return dev_err_probe(&pdev->dev, ret, "failed to register LED device\n");
> }
> dev_info(&pdev->dev, "MEN 140F21P00 BMC LED device enabled\n");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260723164612.3146-1-arun07172003@gmail.com?part=3
next prev parent reply other threads:[~2026-07-23 16:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 16:46 [PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION Arunachalam
2026-07-23 16:46 ` [PATCH v2 2/4] leds: lp8788: convert to dev_err_probe() Arunachalam
2026-07-23 16:56 ` sashiko-bot
2026-07-23 16:46 ` [PATCH v2 3/4] leds: menf21bmc: " Arunachalam
2026-07-23 16:56 ` sashiko-bot [this message]
2026-07-23 16:46 ` [PATCH v2 4/4] leds: 88pm860x: " Arunachalam
2026-07-23 17:02 ` sashiko-bot
2026-07-23 16:56 ` [PATCH v2 1/4] leds: cobalt-raq: add missing MODULE_DESCRIPTION sashiko-bot
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=20260723165650.D619D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=arun07172003@gmail.com \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox