Re: [PATCH v3] scsi: core: Fix async_scan race condition with READ_ONCE/WRITE_ONCE
From: John Garry
Date: Wed Mar 04 2026 - 05:00:07 EST
On 04/03/2026 09: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:Yes. In theory, there is no need for READ-ONCE/WRITE-ONCE.
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?
Then I understand that in practice that there is no need (for READ/WRITE_ONCE), but having it will do no harm, as you mention below.
Plus, this belongs
to defensive programming.
You could mention what this in the commit log.
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.
Reviewed-by: John Garry <john.g.garry@xxxxxxxxxx>