On Mon, Jun 30, 2025 at 5:36 PM Jan Kara <jack@xxxxxxx> wrote: > > On Tue 24-06-25 08:30:03, Amir Goldstein wrote: > > On Mon, Jun 23, 2025 at 9:26 PM Ibrahim Jirdeh <ibrahimjirdeh@xxxxxxxx> 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@xxxxxxxxx> > > Link: https://lore.kernel.org/linux-fsdevel/CAOQ4uxi6PvAcT1vL0d0e+7YjvkfU-kwFVVMAN-tc-FKXe1wtSg@xxxxxxxxxxxxxx/ > > Signed-off-by: Ibrahim Jirdeh <ibrahimjirdeh@xxxxxxxx> > > > > 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@xxxxxxxx> > SUSE Labs, CR
