Re: [PATCH v2] fsnotify: Avoid data race between fsnotify_recalc_mask() and fsnotify_object_watched()

[Marco Elver <elver@google.com>]

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@syzkaller.appspotmail.com
> > Reported-by: Dmitry Vyukov <dvyukov@google.com>
> > Link: https://lore.kernel.org/all/CACT4Y+Zk0ohwwwHSD63U2-PQ=UuamXczr1mKBD6xtj2dyYKBvA@mail.gmail.com
> > Signed-off-by: Jan Kara <jack@suse.cz>
> 
> 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.