MAINTAINERS | 2 + arch/Kconfig | 11 +++ arch/alpha/Kconfig | 1 + arch/alpha/include/asm/rwonce.h | 4 +- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/rwonce.h | 4 +- rust/helpers/helpers.c | 1 + rust/helpers/rwonce.c | 34 +++++++ rust/kernel/fs/file.rs | 8 +- rust/kernel/sync.rs | 2 + rust/kernel/sync/rwonce.rs | 207 ++++++++++++++++++++++++++++++++++++++++ rust/kernel/time/hrtimer.rs | 8 +- 12 files changed, 268 insertions(+), 15 deletions(-)
There are currently a few places in the kernel where we use volatile
reads when we really should be using `READ_ONCE`. To make it possible to
replace these with proper `READ_ONCE` calls, introduce a Rust version of
`READ_ONCE`.
A new config option CONFIG_ARCH_USE_CUSTOM_READ_ONCE is introduced so
that Rust is able to use conditional compilation to implement READ_ONCE
in terms of either a volatile read, or by calling into a C helper
function, depending on the architecture.
This series is intended to be merged through ATOMIC INFRASTRUCTURE.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Alice Ryhl (5):
arch: add CONFIG_ARCH_USE_CUSTOM_READ_ONCE for arm64/alpha
rust: sync: add READ_ONCE and WRITE_ONCE
rust: sync: support using bool with READ_ONCE
rust: hrtimer: use READ_ONCE instead of read_volatile
rust: fs: use READ_ONCE instead of read_volatile
MAINTAINERS | 2 +
arch/Kconfig | 11 +++
arch/alpha/Kconfig | 1 +
arch/alpha/include/asm/rwonce.h | 4 +-
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/rwonce.h | 4 +-
rust/helpers/helpers.c | 1 +
rust/helpers/rwonce.c | 34 +++++++
rust/kernel/fs/file.rs | 8 +-
rust/kernel/sync.rs | 2 +
rust/kernel/sync/rwonce.rs | 207 ++++++++++++++++++++++++++++++++++++++++
rust/kernel/time/hrtimer.rs | 8 +-
12 files changed, 268 insertions(+), 15 deletions(-)
---
base-commit: f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da
change-id: 20251230-rwonce-1e8d2ee0bcf9
Best regards,
--
Alice Ryhl <aliceryhl@google.com>
On Wed, 31 Dec 2025 12:22:24 +0000 Alice Ryhl <aliceryhl@google.com> wrote: > There are currently a few places in the kernel where we use volatile > reads when we really should be using `READ_ONCE`. To make it possible to > replace these with proper `READ_ONCE` calls, introduce a Rust version of > `READ_ONCE`. > > A new config option CONFIG_ARCH_USE_CUSTOM_READ_ONCE is introduced so > that Rust is able to use conditional compilation to implement READ_ONCE > in terms of either a volatile read, or by calling into a C helper > function, depending on the architecture. > > This series is intended to be merged through ATOMIC INFRASTRUCTURE. Hi Alice, I would prefer not to expose the READ_ONCE/WRITE_ONCE functions, at least not with their atomic semantics. Both callsites that you have converted should be using Atomic::from_ptr().load(Relaxed) Please refer to the documentation of `Atomic` about this. Fujita has a series that expand the type to u8/u16 if you need narrower accesses. Best, Gary > > Signed-off-by: Alice Ryhl <aliceryhl@google.com> > --- > Alice Ryhl (5): > arch: add CONFIG_ARCH_USE_CUSTOM_READ_ONCE for arm64/alpha > rust: sync: add READ_ONCE and WRITE_ONCE > rust: sync: support using bool with READ_ONCE > rust: hrtimer: use READ_ONCE instead of read_volatile > rust: fs: use READ_ONCE instead of read_volatile > > MAINTAINERS | 2 + > arch/Kconfig | 11 +++ > arch/alpha/Kconfig | 1 + > arch/alpha/include/asm/rwonce.h | 4 +- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/rwonce.h | 4 +- > rust/helpers/helpers.c | 1 + > rust/helpers/rwonce.c | 34 +++++++ > rust/kernel/fs/file.rs | 8 +- > rust/kernel/sync.rs | 2 + > rust/kernel/sync/rwonce.rs | 207 ++++++++++++++++++++++++++++++++++++++++ > rust/kernel/time/hrtimer.rs | 8 +- > 12 files changed, 268 insertions(+), 15 deletions(-) > --- > base-commit: f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da > change-id: 20251230-rwonce-1e8d2ee0bcf9 > > Best regards,
On Wed, Dec 31, 2025 at 03:12:16PM +0000, Gary Guo wrote: > On Wed, 31 Dec 2025 12:22:24 +0000 > Alice Ryhl <aliceryhl@google.com> wrote: > > > There are currently a few places in the kernel where we use volatile > > reads when we really should be using `READ_ONCE`. To make it possible to > > replace these with proper `READ_ONCE` calls, introduce a Rust version of > > `READ_ONCE`. > > > > A new config option CONFIG_ARCH_USE_CUSTOM_READ_ONCE is introduced so > > that Rust is able to use conditional compilation to implement READ_ONCE > > in terms of either a volatile read, or by calling into a C helper > > function, depending on the architecture. > > > > This series is intended to be merged through ATOMIC INFRASTRUCTURE. > > Hi Alice, > > I would prefer not to expose the READ_ONCE/WRITE_ONCE functions, at > least not with their atomic semantics. > > Both callsites that you have converted should be using > > Atomic::from_ptr().load(Relaxed) > > Please refer to the documentation of `Atomic` about this. Fujita has a > series that expand the type to u8/u16 if you need narrower accesses. Why? If we say that we're using the LKMM, then it seems confusing to not have a READ_ONCE() for cases where we interact with C code, and that C code documents that READ_ONCE() should be used. Alice
On Thu, Jan 01, 2026 at 12:53:39AM +0000, Alice Ryhl wrote: > On Wed, Dec 31, 2025 at 03:12:16PM +0000, Gary Guo wrote: > > On Wed, 31 Dec 2025 12:22:24 +0000 > > Alice Ryhl <aliceryhl@google.com> wrote: > > > > > There are currently a few places in the kernel where we use volatile > > > reads when we really should be using `READ_ONCE`. To make it possible to > > > replace these with proper `READ_ONCE` calls, introduce a Rust version of > > > `READ_ONCE`. > > > > > > A new config option CONFIG_ARCH_USE_CUSTOM_READ_ONCE is introduced so > > > that Rust is able to use conditional compilation to implement READ_ONCE > > > in terms of either a volatile read, or by calling into a C helper > > > function, depending on the architecture. > > > > > > This series is intended to be merged through ATOMIC INFRASTRUCTURE. > > > > Hi Alice, > > > > I would prefer not to expose the READ_ONCE/WRITE_ONCE functions, at > > least not with their atomic semantics. > > > > Both callsites that you have converted should be using > > > > Atomic::from_ptr().load(Relaxed) > > > > Please refer to the documentation of `Atomic` about this. Fujita has a > > series that expand the type to u8/u16 if you need narrower accesses. > > Why? If we say that we're using the LKMM, then it seems confusing to not > have a READ_ONCE() for cases where we interact with C code, and that C > code documents that READ_ONCE() should be used. > The problem of READ_ONCE() and WRITE_ONCE() is that the semantics is complicated. Sometimes they are used for atomicity, sometimes they are used for preventing data race. So yes, we are using LKMM in Rust as well, but whenever possible, we need to clarify the intentation of the API, using Atomic::from_ptr().load(Relaxed) helps on that front. IMO, READ_ONCE()/WRITE_ONCE() is like a "band aid" solution to a few problems, having it would prevent us from developing a more clear view for concurrent programming. Regards, Boqun > Alice
"Boqun Feng" <boqun.feng@gmail.com> writes: > On Thu, Jan 01, 2026 at 12:53:39AM +0000, Alice Ryhl wrote: >> On Wed, Dec 31, 2025 at 03:12:16PM +0000, Gary Guo wrote: >> > On Wed, 31 Dec 2025 12:22:24 +0000 >> > Alice Ryhl <aliceryhl@google.com> wrote: >> > >> > > There are currently a few places in the kernel where we use volatile >> > > reads when we really should be using `READ_ONCE`. To make it possible to >> > > replace these with proper `READ_ONCE` calls, introduce a Rust version of >> > > `READ_ONCE`. >> > > >> > > A new config option CONFIG_ARCH_USE_CUSTOM_READ_ONCE is introduced so >> > > that Rust is able to use conditional compilation to implement READ_ONCE >> > > in terms of either a volatile read, or by calling into a C helper >> > > function, depending on the architecture. >> > > >> > > This series is intended to be merged through ATOMIC INFRASTRUCTURE. >> > >> > Hi Alice, >> > >> > I would prefer not to expose the READ_ONCE/WRITE_ONCE functions, at >> > least not with their atomic semantics. >> > >> > Both callsites that you have converted should be using >> > >> > Atomic::from_ptr().load(Relaxed) >> > >> > Please refer to the documentation of `Atomic` about this. Fujita has a >> > series that expand the type to u8/u16 if you need narrower accesses. >> >> Why? If we say that we're using the LKMM, then it seems confusing to not >> have a READ_ONCE() for cases where we interact with C code, and that C >> code documents that READ_ONCE() should be used. >> > > The problem of READ_ONCE() and WRITE_ONCE() is that the semantics is > complicated. Sometimes they are used for atomicity, sometimes they are > used for preventing data race. So yes, we are using LKMM in Rust as > well, but whenever possible, we need to clarify the intentation of the > API, using Atomic::from_ptr().load(Relaxed) helps on that front. > > IMO, READ_ONCE()/WRITE_ONCE() is like a "band aid" solution to a few > problems, having it would prevent us from developing a more clear view > for concurrent programming. What is the semantics of a non-atomic write in C code under lock racing with a READ_ONCE/atomic relaxed read in Rust? That is the hrtimer case. Best regards, Andreas Hindborg
On Tue, Jan 06, 2026 at 01:41:33PM +0100, Andreas Hindborg wrote: > "Boqun Feng" <boqun.feng@gmail.com> writes: > [...] > >> > I would prefer not to expose the READ_ONCE/WRITE_ONCE functions, at > >> > least not with their atomic semantics. > >> > > >> > Both callsites that you have converted should be using > >> > > >> > Atomic::from_ptr().load(Relaxed) > >> > > >> > Please refer to the documentation of `Atomic` about this. Fujita has a > >> > series that expand the type to u8/u16 if you need narrower accesses. > >> > >> Why? If we say that we're using the LKMM, then it seems confusing to not > >> have a READ_ONCE() for cases where we interact with C code, and that C > >> code documents that READ_ONCE() should be used. > >> > > > > The problem of READ_ONCE() and WRITE_ONCE() is that the semantics is > > complicated. Sometimes they are used for atomicity, sometimes they are > > used for preventing data race. So yes, we are using LKMM in Rust as > > well, but whenever possible, we need to clarify the intentation of the > > API, using Atomic::from_ptr().load(Relaxed) helps on that front. > > > > IMO, READ_ONCE()/WRITE_ONCE() is like a "band aid" solution to a few > > problems, having it would prevent us from developing a more clear view > > for concurrent programming. > > What is the semantics of a non-atomic write in C code under lock racing > with a READ_ONCE/atomic relaxed read in Rust? That is the hrtimer case. > Some C code believes a plain write to a properly aligned location is atomic (see KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, and no, this doesn't mean it's recommended to assume such), and I guess that's the case for hrtimer, if it's not much a trouble you can replace the plain write with WRITE_ONCE() on C side ;-) Regards, Boqun > > Best regards, > Andreas Hindborg > > >
On Tue, Jan 06, 2026 at 09:09:37PM +0800, Boqun Feng wrote: > Some C code believes a plain write to a properly aligned location is > atomic (see KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, and no, this doesn't mean > it's recommended to assume such), and I guess that's the case for > hrtimer, if it's not much a trouble you can replace the plain write with > WRITE_ONCE() on C side ;-) GCC used to provide this guarantee, some of the older code was written on that. GCC no longer provides that guarantee (there are known cases where it breaks and all that) and newer code should not rely on this. All such places *SHOULD* be updated to use READ_ONCE/WRITE_ONCE.
On Tue, Jan 06, 2026 at 03:56:22PM +0100, Peter Zijlstra wrote: > On Tue, Jan 06, 2026 at 09:09:37PM +0800, Boqun Feng wrote: > > > Some C code believes a plain write to a properly aligned location is > > atomic (see KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, and no, this doesn't mean > > it's recommended to assume such), and I guess that's the case for > > hrtimer, if it's not much a trouble you can replace the plain write with > > WRITE_ONCE() on C side ;-) > > GCC used to provide this guarantee, some of the older code was written > on that. GCC no longer provides that guarantee (there are known cases > where it breaks and all that) and newer code should not rely on this. > > All such places *SHOULD* be updated to use READ_ONCE/WRITE_ONCE. Agreed! In that vein, any objections to the patch shown below? Thanx, Paul ------------------------------------------------------------------------ diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan index 4ce4b0c0109cb..e827e24ab5d42 100644 --- a/lib/Kconfig.kcsan +++ b/lib/Kconfig.kcsan @@ -199,7 +199,7 @@ config KCSAN_WEAK_MEMORY config KCSAN_REPORT_VALUE_CHANGE_ONLY bool "Only report races where watcher observed a data value change" - default y + default n depends on !KCSAN_STRICT help If enabled and a conflicting write is observed via a watchpoint, but @@ -208,7 +208,7 @@ config KCSAN_REPORT_VALUE_CHANGE_ONLY config KCSAN_ASSUME_PLAIN_WRITES_ATOMIC bool "Assume that plain aligned writes up to word size are atomic" - default y + default n depends on !KCSAN_STRICT help Assume that plain aligned writes up to word size are atomic by
On Tue, Jan 06, 2026 at 10:18:35AM -0800, Paul E. McKenney wrote: > On Tue, Jan 06, 2026 at 03:56:22PM +0100, Peter Zijlstra wrote: > > On Tue, Jan 06, 2026 at 09:09:37PM +0800, Boqun Feng wrote: > > > > > Some C code believes a plain write to a properly aligned location is > > > atomic (see KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, and no, this doesn't mean > > > it's recommended to assume such), and I guess that's the case for > > > hrtimer, if it's not much a trouble you can replace the plain write with > > > WRITE_ONCE() on C side ;-) > > > > GCC used to provide this guarantee, some of the older code was written > > on that. GCC no longer provides that guarantee (there are known cases > > where it breaks and all that) and newer code should not rely on this. > > > > All such places *SHOULD* be updated to use READ_ONCE/WRITE_ONCE. > > Agreed! > > In that vein, any objections to the patch shown below? Not really; although it would of course be nice if that were accompanied with a pile of cleanup patches taking out the worst offenders or somesuch ;-) > ------------------------------------------------------------------------ > > diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan > index 4ce4b0c0109cb..e827e24ab5d42 100644 > --- a/lib/Kconfig.kcsan > +++ b/lib/Kconfig.kcsan > @@ -199,7 +199,7 @@ config KCSAN_WEAK_MEMORY > > config KCSAN_REPORT_VALUE_CHANGE_ONLY > bool "Only report races where watcher observed a data value change" > - default y > + default n > depends on !KCSAN_STRICT > help > If enabled and a conflicting write is observed via a watchpoint, but > @@ -208,7 +208,7 @@ config KCSAN_REPORT_VALUE_CHANGE_ONLY > > config KCSAN_ASSUME_PLAIN_WRITES_ATOMIC > bool "Assume that plain aligned writes up to word size are atomic" > - default y > + default n > depends on !KCSAN_STRICT > help > Assume that plain aligned writes up to word size are atomic by
On Wed, Jan 07, 2026 at 09:43:22AM +0100, Peter Zijlstra wrote: > On Tue, Jan 06, 2026 at 10:18:35AM -0800, Paul E. McKenney wrote: > > On Tue, Jan 06, 2026 at 03:56:22PM +0100, Peter Zijlstra wrote: > > > On Tue, Jan 06, 2026 at 09:09:37PM +0800, Boqun Feng wrote: > > > > > > > Some C code believes a plain write to a properly aligned location is > > > > atomic (see KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, and no, this doesn't mean > > > > it's recommended to assume such), and I guess that's the case for > > > > hrtimer, if it's not much a trouble you can replace the plain write with > > > > WRITE_ONCE() on C side ;-) > > > > > > GCC used to provide this guarantee, some of the older code was written > > > on that. GCC no longer provides that guarantee (there are known cases > > > where it breaks and all that) and newer code should not rely on this. > > > > > > All such places *SHOULD* be updated to use READ_ONCE/WRITE_ONCE. > > > > Agreed! > > > > In that vein, any objections to the patch shown below? > > Not really; although it would of course be nice if that were accompanied > with a pile of cleanup patches taking out the worst offenders or > somesuch ;-) Careful what you ask for. You might get it... ;-) Thanx, Paul > > ------------------------------------------------------------------------ > > > > diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan > > index 4ce4b0c0109cb..e827e24ab5d42 100644 > > --- a/lib/Kconfig.kcsan > > +++ b/lib/Kconfig.kcsan > > @@ -199,7 +199,7 @@ config KCSAN_WEAK_MEMORY > > > > config KCSAN_REPORT_VALUE_CHANGE_ONLY > > bool "Only report races where watcher observed a data value change" > > - default y > > + default n > > depends on !KCSAN_STRICT > > help > > If enabled and a conflicting write is observed via a watchpoint, but > > @@ -208,7 +208,7 @@ config KCSAN_REPORT_VALUE_CHANGE_ONLY > > > > config KCSAN_ASSUME_PLAIN_WRITES_ATOMIC > > bool "Assume that plain aligned writes up to word size are atomic" > > - default y > > + default n > > depends on !KCSAN_STRICT > > help > > Assume that plain aligned writes up to word size are atomic by
On Tue, 6 Jan 2026 at 19:18, 'Paul E. McKenney' via kasan-dev <kasan-dev@googlegroups.com> wrote: > On Tue, Jan 06, 2026 at 03:56:22PM +0100, Peter Zijlstra wrote: > > On Tue, Jan 06, 2026 at 09:09:37PM +0800, Boqun Feng wrote: > > > > > Some C code believes a plain write to a properly aligned location is > > > atomic (see KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, and no, this doesn't mean > > > it's recommended to assume such), and I guess that's the case for > > > hrtimer, if it's not much a trouble you can replace the plain write with > > > WRITE_ONCE() on C side ;-) > > > > GCC used to provide this guarantee, some of the older code was written > > on that. GCC no longer provides that guarantee (there are known cases > > where it breaks and all that) and newer code should not rely on this. > > > > All such places *SHOULD* be updated to use READ_ONCE/WRITE_ONCE. > > Agreed! > > In that vein, any objections to the patch shown below? I'd be in favor, as that's what we did in the very initial version of KCSAN (we started strict and then loosened things up). However, the fallout will be even more perceived "noise", despite being legitimate data races. These config knobs were added after much discussion in 2019/2020, somewhere around this discussion (I think that's the one that spawned KCSAN_REPORT_VALUE_CHANGE_ONLY, can't find the source for KCSAN_ASSUME_PLAIN_WRITES_ATOMIC): https://lore.kernel.org/all/CAHk-=wgu-QXU83ai4XBnh7JJUo2NBW41XhLWf=7wrydR4=ZP0g@mail.gmail.com/ While the situation has gotten better since 2020, we still have latent data races that need some thought (given papering over things blindly with *ONCE is not right either). My recommendation these days is to just set CONFIG_KCSAN_STRICT=y for those who care (although I'd wish everyone cared the same amount :-)). Should you feel the below change is appropriate for 2026, feel free to carry it (consider this my Ack). However, I wasn't thinking of tightening the screws until the current set of known data races has gotten to a manageable amount (say below 50) https://syzkaller.appspot.com/upstream?manager=ci2-upstream-kcsan-gce Then again, on syzbot the config can remain unchanged. Thanks, -- Marco > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan > index 4ce4b0c0109cb..e827e24ab5d42 100644 > --- a/lib/Kconfig.kcsan > +++ b/lib/Kconfig.kcsan > @@ -199,7 +199,7 @@ config KCSAN_WEAK_MEMORY > > config KCSAN_REPORT_VALUE_CHANGE_ONLY > bool "Only report races where watcher observed a data value change" > - default y > + default n > depends on !KCSAN_STRICT > help > If enabled and a conflicting write is observed via a watchpoint, but > @@ -208,7 +208,7 @@ config KCSAN_REPORT_VALUE_CHANGE_ONLY > > config KCSAN_ASSUME_PLAIN_WRITES_ATOMIC > bool "Assume that plain aligned writes up to word size are atomic" > - default y > + default n > depends on !KCSAN_STRICT > help > Assume that plain aligned writes up to word size are atomic by >
On Tue, Jan 06, 2026 at 08:28:41PM +0100, Marco Elver wrote: > On Tue, 6 Jan 2026 at 19:18, 'Paul E. McKenney' via kasan-dev > <kasan-dev@googlegroups.com> wrote: > > On Tue, Jan 06, 2026 at 03:56:22PM +0100, Peter Zijlstra wrote: > > > On Tue, Jan 06, 2026 at 09:09:37PM +0800, Boqun Feng wrote: > > > > > > > Some C code believes a plain write to a properly aligned location is > > > > atomic (see KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, and no, this doesn't mean > > > > it's recommended to assume such), and I guess that's the case for > > > > hrtimer, if it's not much a trouble you can replace the plain write with > > > > WRITE_ONCE() on C side ;-) > > > > > > GCC used to provide this guarantee, some of the older code was written > > > on that. GCC no longer provides that guarantee (there are known cases > > > where it breaks and all that) and newer code should not rely on this. > > > > > > All such places *SHOULD* be updated to use READ_ONCE/WRITE_ONCE. > > > > Agreed! > > > > In that vein, any objections to the patch shown below? > > I'd be in favor, as that's what we did in the very initial version of > KCSAN (we started strict and then loosened things up). > > However, the fallout will be even more perceived "noise", despite > being legitimate data races. These config knobs were added after much > discussion in 2019/2020, somewhere around this discussion (I think > that's the one that spawned KCSAN_REPORT_VALUE_CHANGE_ONLY, can't find > the source for KCSAN_ASSUME_PLAIN_WRITES_ATOMIC): > https://lore.kernel.org/all/CAHk-=wgu-QXU83ai4XBnh7JJUo2NBW41XhLWf=7wrydR4=ZP0g@mail.gmail.com/ Fair point! > While the situation has gotten better since 2020, we still have latent > data races that need some thought (given papering over things blindly > with *ONCE is not right either). My recommendation these days is to > just set CONFIG_KCSAN_STRICT=y for those who care (although I'd wish > everyone cared the same amount :-)). > > Should you feel the below change is appropriate for 2026, feel free to > carry it (consider this my Ack). > > However, I wasn't thinking of tightening the screws until the current > set of known data races has gotten to a manageable amount (say below > 50) > https://syzkaller.appspot.com/upstream?manager=ci2-upstream-kcsan-gce > Then again, on syzbot the config can remain unchanged. Is there an easy way to map from a report to the SHA-1 that the corresponding test ran against? Probably me being blind, but I am not seeing it. Though I do very much like the symbolic names in those stack traces! Thanx, Paul > Thanks, > -- Marco > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan > > index 4ce4b0c0109cb..e827e24ab5d42 100644 > > --- a/lib/Kconfig.kcsan > > +++ b/lib/Kconfig.kcsan > > @@ -199,7 +199,7 @@ config KCSAN_WEAK_MEMORY > > > > config KCSAN_REPORT_VALUE_CHANGE_ONLY > > bool "Only report races where watcher observed a data value change" > > - default y > > + default n > > depends on !KCSAN_STRICT > > help > > If enabled and a conflicting write is observed via a watchpoint, but > > @@ -208,7 +208,7 @@ config KCSAN_REPORT_VALUE_CHANGE_ONLY > > > > config KCSAN_ASSUME_PLAIN_WRITES_ATOMIC > > bool "Assume that plain aligned writes up to word size are atomic" > > - default y > > + default n > > depends on !KCSAN_STRICT > > help > > Assume that plain aligned writes up to word size are atomic by > >
On Fri, 9 Jan 2026 at 03:09, Paul E. McKenney <paulmck@kernel.org> wrote: > > On Tue, Jan 06, 2026 at 08:28:41PM +0100, Marco Elver wrote: > > On Tue, 6 Jan 2026 at 19:18, 'Paul E. McKenney' via kasan-dev > > <kasan-dev@googlegroups.com> wrote: > > > On Tue, Jan 06, 2026 at 03:56:22PM +0100, Peter Zijlstra wrote: > > > > On Tue, Jan 06, 2026 at 09:09:37PM +0800, Boqun Feng wrote: > > > > > > > > > Some C code believes a plain write to a properly aligned location is > > > > > atomic (see KCSAN_ASSUME_PLAIN_WRITES_ATOMIC, and no, this doesn't mean > > > > > it's recommended to assume such), and I guess that's the case for > > > > > hrtimer, if it's not much a trouble you can replace the plain write with > > > > > WRITE_ONCE() on C side ;-) > > > > > > > > GCC used to provide this guarantee, some of the older code was written > > > > on that. GCC no longer provides that guarantee (there are known cases > > > > where it breaks and all that) and newer code should not rely on this. > > > > > > > > All such places *SHOULD* be updated to use READ_ONCE/WRITE_ONCE. > > > > > > Agreed! > > > > > > In that vein, any objections to the patch shown below? > > > > I'd be in favor, as that's what we did in the very initial version of > > KCSAN (we started strict and then loosened things up). > > > > However, the fallout will be even more perceived "noise", despite > > being legitimate data races. These config knobs were added after much > > discussion in 2019/2020, somewhere around this discussion (I think > > that's the one that spawned KCSAN_REPORT_VALUE_CHANGE_ONLY, can't find > > the source for KCSAN_ASSUME_PLAIN_WRITES_ATOMIC): > > https://lore.kernel.org/all/CAHk-=wgu-QXU83ai4XBnh7JJUo2NBW41XhLWf=7wrydR4=ZP0g@mail.gmail.com/ > > Fair point! > > > While the situation has gotten better since 2020, we still have latent > > data races that need some thought (given papering over things blindly > > with *ONCE is not right either). My recommendation these days is to > > just set CONFIG_KCSAN_STRICT=y for those who care (although I'd wish > > everyone cared the same amount :-)). > > > > Should you feel the below change is appropriate for 2026, feel free to > > carry it (consider this my Ack). > > > > However, I wasn't thinking of tightening the screws until the current > > set of known data races has gotten to a manageable amount (say below > > 50) > > https://syzkaller.appspot.com/upstream?manager=ci2-upstream-kcsan-gce > > Then again, on syzbot the config can remain unchanged. > > Is there an easy way to map from a report to the SHA-1 that the > corresponding test ran against? Probably me being blind, but I am not > seeing it. Though I do very much like the symbolic names in those > stack traces! When viewing a report page, at the bottom in the "Crashes" table it's in the "Commit" column.
© 2016 - 2026 Red Hat, Inc.