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

[Runyu Xiao]

You're right, and "tested" was the wrong word in my reply.

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.

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.

Thanks,
Runyu Xiao