Re: [PATCH] staging: greybus: light: initialize channel lock before registration

[Greg Kroah-Hartman]

On Wed, Aug 19, 2026 at 09:21:08PM +0800, Runyu Xiao wrote:
> You're right, and "tested" was the wrong word in my reply.

Sorry, I have no context :(

Remember, some of us get thousands of emails a day.

> The finding here is from code inspection, not from a runtime test. The
> path I checked is:
> 
>   gb_lights_channel_register()
>     -> led_classdev_register()
>        publishes cdev->brightness_set_blocking
>        (= gb_brightness_set()
>           -> __gb_lights_brightness_set()
>           -> __gb_lights_led_brightness_set()
>           -> mutex_lock(&channel->lock))
> 
> but mutex_init(&channel->lock) only runs after
> gb_lights_channel_register() returns, and that is the only place where
> channel->lock is initialized. So the lock is published before it is
> initialized.
> 
> The QEMU module I mentioned does not exercise this driver. It only shows
> that taking an uninitialized mutex triggers the expected
> DEBUG_LOCKS_WARN_ON(lock->magic != lock), so I should not have described
> it as driver testing or as a reproducer for this driver.
> 
> And yes, 6.1.66 was only the kernel version in that local QEMU setup. The
> patch itself was made and compile-checked against current mainline, and
> I'll keep validation against mainline for future submissions.

Just build testing against a many-year-old kernel is a sure way to
ensure that nothing will actually work at all :(

> The initial report came from PatchProof, a static-analysis pipeline I am
> building for lock-API misuse. It flagged this publish-before-init ordering,
> and I then manually verified the call path above. I did use an LLM as an
> assistant during the workflow, but the finding itself was from the checker
> and the patch I sent was based on my manual review of the code.

Please read the archives for why we don't take LLM patches for
drivers/staging/ unless you can test the change on real hardware.

thanks,

greg k-h