Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Uninitialized `backlight_notifier` rwsem leads to kernel panic on registration if `backlight_class_init()` fails. --
commit d337f12d53eda5facdddbe940d5c74c91750178b Author: Mario Limonciello <[email protected]> Revert "backlight: Remove notifier" This commit reverts the removal of the backlight notifier support, as it is needed to add backlight control support into DRM connectors. > diff --git a/drivers/video/backlight/backlight.c > b/drivers/video/backlight/backlight.c > index fc9bb303e8c5f..4401f6294ccc8 100644 > --- a/drivers/video/backlight/backlight.c > +++ b/drivers/video/backlight/backlight.c > @@ -65,6 +65,7 @@ > > static struct list_head backlight_dev_list; > static struct mutex backlight_dev_list_mutex; > +static struct blocking_notifier_head backlight_notifier; [Severity: High] Does this zero-initialized notifier head lead to a kernel panic if backlight_class_init() in drivers/video/backlight/backlight.c fails? If class_register() fails in backlight_class_init() due to memory pressure or sysfs issues, the function will return early and skip the dynamic initialization via BLOCKING_INIT_NOTIFIER_HEAD(). When a subsequent caller calls backlight_register_notifier(), it will pass this zero-initialized notifier to blocking_notifier_chain_register(), which will attempt to lock the uninitialized rw_semaphore and cause an oops. Could this be prevented by using the static initialization macro instead? static BLOCKING_NOTIFIER_HEAD(backlight_notifier); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
