Re: [syzbot] [kernel?] KCSAN: data-race in kobject_put / kobject_uevent_env (2)

[Tetsuo Handa]

On 2024/07/18 20:09, Greg KH wrote:
> On Thu, Jul 18, 2024 at 12:38:05PM +0200, Marco Elver wrote:
>> The two racing accesses here (on bitfield variables
>> kobj->state_remove_uevent_sent, kobj->state_initialized) are in the
>> same bitfield. There's no guarantee (by the compiler) that while the
>> bitfield is being updated the bit at kobj->state_initialized will
>> remain non-zero, and therefore the WARN in kobject_put() could be
>> triggered. This appears benign, unless of course someone set
>> panic_on_warn.
>>
>> More generally, if the bitfield is updated concurrently, it's very
>> likely that one of the updates would be lost.
>>
>> Just my initial observation.
> 
> Thanks for the review, I'll try to carve out some time next week to
> knock up a patch for this...

Unless it is proven that these

	unsigned int state_initialized:1;
	unsigned int state_in_sysfs:1;
	unsigned int state_add_uevent_sent:1;
	unsigned int state_remove_uevent_sent:1;
	unsigned int uevent_suppress:1;

fields are never modified concurrently, just marking this "unsigned int" as
__data_racy is wrong.

When we hit unprotected bitmask modification bug at
https://lkml.kernel.org/r/201409192053.IHJ35462.JLOMOSOFFVtQFH@xxxxxxxxxxxxxxxxxxx ,
we fixed the race by converting to test_bit()/set_bit()/clear_bit().