On Mon, Jul 15, 2024 at 10:22AM -0400, Josef Bacik wrote: > On Mon, Jul 15, 2024 at 03:04:10PM +0200, Jan Kara wrote: > > When __fsnotify_recalc_mask() recomputes the mask on the watched object, > > the compiler can "optimize" the code to perform partial updates to the > > mask (including zeroing it at the beginning). Thus places checking > > the object mask without conn->lock such as fsnotify_object_watched() > > could see invalid states of the mask. Make sure the mask update is > > performed by one memory store using WRITE_ONCE(). > > > > Reported-by: syzbot+701037856c25b143f1ad@xxxxxxxxxxxxxxxxxxxxxxxxx > > Reported-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > > Link: https://lore.kernel.org/all/CACT4Y+Zk0ohwwwHSD63U2-PQ=UuamXczr1mKBD6xtj2dyYKBvA@xxxxxxxxxxxxxx > > Signed-off-by: Jan Kara <jack@xxxxxxx> > > I'm still hazy on the rules here and what KCSAN expects, but if we're using > READ_ONCE/WRITE_ONCE on a thing, do we have to use them everywhere we access > that member? Because there's a few accesses in include/linux/fsnotify_backend.h > that were missed if so. Thanks, Only if they can be concurrently read + written. Per Linux's memory model, plain concurrent accesses, where at least one is a write, are data races. Data races are hard to reason about, because the compiler is free to shuffle unmarked accesses around as it pleases, along with other transformations that break atomicity and any ordering assumptions. (Data races can also be a symptom of missing locking or other missed serialization, but that does not seem to the case here.) This is a reasonable overview: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt I don't know the code well enough here, but the above commit message also mentions a "conn->lock". E.g. if all accesses under the lock are serialized, they won't need to be marked with ONCE. But the lock won't help if e.g. there are accesses within a lock critical section, but also accesses outside the critical section, in which case both sides need to be marked again (even the ones under the lock). A good concurrent stress test + KCSAN is pretty good about quickly telling you about data races.
