Re: [PATCH v3] scsi: core: Fix async_scan race condition with READ_ONCE/WRITE_ONCE
From: Bart Van Assche
Date: Wed Mar 04 2026 - 07:21:54 EST
On 3/4/26 3:43 AM, 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. Plus, this belongs
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?
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.
Using READ_ONCE() / WRITE_ONCE() for member variables protected by a
mutex is wrong because it confuses people who read the code. Please use
__guarded_by() to document that the async_scan member is protected by
the scan_mutex. More information about __guarded_by(), introduced during
the 7.0 merge window, is available in
Documentation/dev-tools/context-analysis.rst. As one can see in that
document, Clang 22 or later is needed to verify __guarded_by()
annotations during compilation. Information about how to build the
kernel with Clang is available in Documentation/kbuild/llvm.rst.
Bart.