Re: [PATCH v3] scsi: core: Fix async_scan race condition with READ_ONCE/WRITE_ONCE

[Damien Le Moal]

On 3/4/26 18:43, Chaohai Chen wrote:
> On Wed, Mar 04, 2026 at 09:20:25AM +0000, John Garry wrote:
>> On 04/03/2026 07:57, Chaohai Chen wrote:
>>> Previously, host_lock was used to prevent bit-set conflicts in async_scan,
>>> but this approach introduced naked reads in some code paths.
>>>
>>> Convert async_scan from a bitfield to a bool type to eliminate bit-level
>>> conflicts entirely. Use READ_ONCE() and WRITE_ONCE() to ensure proper
>>> memory ordering on Alpha and satisfy KCSAN requirements.
>>
>> Is the shost->scan_mutex always held when shost->async_scan is read/written?
>>
> Yes. In theory, there is no need for READ-ONCE/WRITE-ONCE. Plus, this belongs 
> to defensive programming. And it indicates that this is a shared variable, 
> which means that this variable will be accessed by multiple threads and 
> concurrency issues need to be handled carefully.

If the scan_mutex is always held when scan_mutex is used, there will not be
multiple threads, unless there are accessed also from IRQ context, which would
be odd. So I am not sure what concurrency issue you are referring to here.


-- 
Damien Le Moal
Western Digital Research