In the Linux kernel, the following vulnerability has been resolved: workqueue: Fix spruious data race in flushwork() When flushing a work item for cancellation, _flushwork() knows that it exclusively owns the work item through its PENDING bit. 134874e2eee9 ("workqueue: Allow cancelworksync() and disablework() from atomic contexts on BH work items") added a read of @work->data to determine whether to use busy wait for BH work items that are being canceled. While the read is safe when @fromcancel, @work->data was read before testing @fromcancel to simplify code structure: data = *workdatabits(work); if (fromcancel && !WARNONONCE(data & WORKSTRUCTPWQ) && (data & WORKOFFQBH)) { While the read data was never used if !@fromcancel, this could trigger KCSAN data race detection spuriously: ================================================================== BUG: KCSAN: data-race in _flushwork / _flushwork write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0: instrumentwrite include/linux/instrumented.h:41 [inline] _setbit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline] insertwqbarrier kernel/workqueue.c:3790 [inline] startflushwork kernel/workqueue.c:4142 [inline] _flushwork+0x30b/0x570 kernel/workqueue.c:4178 flushwork kernel/workqueue.c:4229 [inline] ... read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1: _flushwork+0x42a/0x570 kernel/workqueue.c:4188 flushwork kernel/workqueue.c:4229 [inline] flushdelayedwork+0x66/0x70 kernel/workqueue.c:4251 ... value changed: 0x0000000000400000 -> 0xffff88810006c00d Reorganize the code so that @fromcancel is tested before @work->data is accessed. The only problem is triggering KCSAN detection spuriously. This shouldn't need READONCE() or other access qualifiers. No functional changes.