On Mon, Jun 30, 2025 at 4:50 PM Jan Kara <jack@xxxxxxx> wrote: > > Hi! > > I agree expanding fanotify_event_metadata painful. After all that's the > reason why we've invented the additional info records in the first place :). > So I agree with putting the id either in a separate info record or overload > something in fanotify_event_metadata. > > On Sun 29-06-25 08:50:05, Amir Goldstein wrote: > > I may have mentioned this before, but I'll bring it up again. > > If we want to overload event->fd with response id I would consider > > allocating response_id with idr_alloc_cyclic() that starts at 256 > > and then set event->fd = -response_id. > > We want to skip the range -1..-255 because it is used to report > > fd open errors with FAN_REPORT_FD_ERROR. > > I kind of like this. It looks elegant. The only reason I'm hesitating is > that as you mentioned with persistent notifications we'll likely need > 64-bit type for identifying event. But OTOH requirements there are unclear > and I can imagine even userspace assigning the ID. In the worst case we > could add info record for this persistent event id. Yes, those persistent id's are inherently different from the response key, so I am not really worried about duplicity. > So ok, let's do it as you suggest. Cool. I don't think that we even need an explicit FAN_REPORT_EVENT_ID, because it is enough to say that (fid_mode != 0) always means that event->fd cannot be >= 0 (like it does today), but with pre-content events event->fd can be a key < -255? Ibrahim, Feel free to post the patches from my branch, if you want post the event->fd = -response_id implementation. I also plan to post them myself when I complete the pre-dir-content patches. Thanks, Amir.
