Re: [PATCH v1 03/12] fsnotify: don't hold a spin_lock across fsnotify_recalc_mask() calls.

[NeilBrown]

On Wed, 19 Aug 2026, Amir Goldstein wrote:
> On Wed, Aug 19, 2026 at 1:30 AM NeilBrown <neilb@xxxxxxxxxxx> wrote:
> > --- a/fs/notify/dnotify/dnotify.c
> > +++ b/fs/notify/dnotify/dnotify.c
> > @@ -75,7 +75,7 @@ static void dnotify_recalc_inode_mask(struct fsnotify_mark *fsn_mark)
> >                 return;
> >         fsn_mark->mask = new_mask;
> >
> > -       fsnotify_recalc_mask(fsn_mark->connector);
> > +       fsnotify_recalc_mask_inatomic(fsn_mark->connector);
> 
> I don't think skipping update_children is correct when called
> from fcntl_dirnotify().

Thanks for catching that.
I agree we shouldn't skip here, but also we mustn't call
fsnotify_conn_set_children_dentry_flags() at this point because
a spinlock is held.
In fcntl_dirnotify() is it safe to delay that call until after the
lock is dropped because fsnotify_group_lock() is still held.

So I would like to keep that part of my patch - the part where
fsnotify_recalc_mask() (and dnotify_recalc_inode_mask()) returns the
"update_children" flag and the caller is responsible for calling
fsnotify_conn_set_children_dentry_flags().

Some callers call fsnotify_conn_set_children_dentry_flags() immediately,
some wait until a spinlock is dropped, dnotify_handle_event() wouldn't
call it at all.

Your patch might be a good addition but it doesn't block the d_children
walk in all cases where a spinlock is held, so it doesn't help my
immediate need.

Thanks,
NeilBrown