Re: [PATCH] fanotify: support custom default close response

[Amir Goldstein <amir73il@gmail.com>]

On Mon, Jun 30, 2025 at 5:36 PM Jan Kara <jack@suse.cz> wrote:
>
> On Tue 24-06-25 08:30:03, Amir Goldstein wrote:
> > On Mon, Jun 23, 2025 at 9:26 PM Ibrahim Jirdeh <ibrahimjirdeh@meta.com> wrote:
> > >
> > > Currently the default response for pending events is FAN_ALLOW.
> > > This makes default close response configurable. The main goal
> > > of these changes would be to provide better handling for pending
> > > events for lazy file loading use cases which may back fanotify
> > > events by a long-lived daemon. For earlier discussion see:
> > > https://lore.kernel.org/linux-fsdevel/6za2mngeqslmqjg3icoubz37hbbxi6bi44canfsg2aajgkialt@c3ujlrjzkppr/
> >
> > These lore links are typically placed at the commit message tail block
> > if related to a suggestion you would typically use:
> >
> > Suggested-by: Amir Goldstein <amir73il@gmail.com>
> > Link: https://lore.kernel.org/linux-fsdevel/CAOQ4uxi6PvAcT1vL0d0e+7YjvkfU-kwFVVMAN-tc-FKXe1wtSg@mail.gmail.com/
> > Signed-off-by: Ibrahim Jirdeh <ibrahimjirdeh@meta.com>
> >
> > This way reviewers whose response is "what a terrible idea!" can
> > point their arrows at me instead of you ;)
> >
> > Note that this is a more accurate link to the message where the default
> > response API was proposed, so readers won't need to sift through
> > this long thread to find the reference.
>
> I've reread that thread to remember how this is supposed to be used. After
> thinking about it now maybe we could just modify how pending fanotify
> events behave in case of group destruction? Instead of setting FAN_ALLOW in
> fanotify_release() we'd set a special event state that will make fanotify
> group iteration code bubble up back to fsnotify() and restart the event
> generation loop there?
>
> In the usual case this would behave the same way as setting FAN_ALLOW (just
> in case of multiple permission event watchers some will get the event two
> times which shouldn't matter). In case of careful design with fd store
> etc., the daemon can setup the new notification group as needed and then
> close the fd from the old notification group at which point it would
> receive all the pending events in the new group. I can even see us adding
> ioctl to the fanotify group which when called will result in the same
> behavior (i.e., all pending permission events will get the "retry"
> response). That way the new daemon could just take the old fd from the fd
> store and call this ioctl to receive all the pending events again.
>
> No need for the new default response. We probably need to provide a group
> feature flag for this so that userspace can safely query kernel support for
> this behavior but otherwise even that wouldn't be really needed.
>
> What do you guys think?

With proper handover I am not sure why this is needed, because:
- new group gets fd from store and signals old group
- old group does not take any new event, completes in-flight events,
  signals back new group and exists
- new group starts processing events
- so why do we need a complex mechanism in kernel to do what can easily
  be done in usersapce?

Also, regardless I think that we need the default response, because:
- groups starts, set default response to DENY and handsover fd to store
- if group crashes unexpectedly, access to all files is denied, which is
  exactly what we needed to do with the "moderated" mount
- it is similar to access to FUSE mount when server is down

For a requirement that non-populated content MUST NOT be
accessed, the default response is a very easy way to achieve it.

Thanks,
Amir.





>
>                                                                 Honza
>
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR