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

[Greg Kroah-Hartman]

On Wed, Aug 19, 2026 at 08:32:45PM +0800, Runyu Xiao wrote:
> On Tue, Aug 18, 2026 at 20:23:10 +0200, Greg Kroah-Hartman wrote:
> > How was this found and tested?
> 
> 
> Found by code inspection: gb_lights_channel_register() publishes the
> LED class device and its brightness callback before
> mutex_init(&light->channels[i].lock) runs, so a concurrent brightness
> update can take an uninitialized mutex.

What tool did this inspection?  A LLM?

> Tested by reproducing that code shape in a minimal out-of-tree module
> under QEMU (kernel 6.1.66 with CONFIG_DEBUG_MUTEXES=y and
> CONFIG_DEBUG_LOCK_ALLOC=y), since the real driver needs greybus/LED
> hardware I don't have. The module kzalloc's a channel, registers
> (publishes) it, and runs the brightness callback, which takes the
> embedded mutex:
> 
> 
>  - before the fix, mutex_init() runs after register, so the callback
>    locks the still-zeroed mutex and trips
> 
> 
>        DEBUG_LOCKS_WARN_ON(lock->magic != lock)
>        WARNING: CPU: 1 PID: 188 at kernel/locking/mutex.c:582 __mutex_lock+0x712/0xd20
> 
> 
>  - after the fix, mutex_init() runs before register and the same
>    trigger path produces no warning.

But that isn't testing anything at all.

And why 6.1.66?  That's not what new patches need to be made against, as
it's years old.

> The real driver hits this as a race (a concurrent brightness update),
> whereas the reproducer runs the callback synchronously during registration
> to make it deterministic; both leave the callback observing an
> uninitialized lock.

What "reproducer"?  Again, was this done by a LLM?  Where is the
"reproducer"?

thanks,

greg k-h