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