Messages in this thread | | | Date | Tue, 3 Mar 2020 20:05:15 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH -next] lib: disable KCSAN for XArray |
| |
On Tue, Mar 03, 2020 at 07:33:29PM -0800, Matthew Wilcox wrote: > On Tue, Mar 03, 2020 at 10:15:51PM -0500, Qian Cai wrote: > > Functions like xas_find_marked(), xas_set_mark(), and xas_clear_mark() > > could happen concurrently result in data races, but those operate only > > on a single bit that are pretty much harmless. For example, > > Those aren't data races. The writes are protected by a spinlock and the > reads by the RCU read lock. If the tool can't handle RCU protection, > it's not going to be much use.
Would KCSAN's ASSERT_EXCLUSIVE_BITS() help here?
If not, you lost me on this one. RCU readers don't exclude lock-based writers.
RCU readers -do- exclude pre-insertion initialization on the one hand, and those post-removal accesses that follow a grace period, but only if that grace period starts after the removal. In addition, the accesses due to rcu_dereference(), rcu_assign_pointer(), and similar are guaranteed to work even if they are concurrent.
Or am I missing something subtle here?
That said, you are permitted to define "data race" for your subsystem by choosing KCSAN settings, up to and including keeping KCSAN out entirely.
Thanx, Paul
| |