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? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
