On Tue, Jul 22, 2025 at 4:01 PM Jan Kara <jack@xxxxxxx> wrote:
>
> Hello!
>
> Sorry for a bit delayed reply I was busy with other work...
>
> On Fri 11-07-25 11:30:59, Ibrahim Jirdeh wrote:
> > From: Amir Goldstein <amir73il@xxxxxxxxx>
> >
> > In preparation for pre-content events that report fid info + name,
> > we need a new event type that is both variable length and can be
> > put on a user response wait list.
> >
> > Create an event type FANOTIFY_EVENT_TYPE_FID_NAME_PERM with is a
> > combination of the variable length fanotify_name_event prefixed
> > with a fix length fanotify_perm_event and they share the common
> > fanotify_event memeber.
> >
> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>
> As a procedural note, this patch should have your Signed-off-by as well
> Ibrahim, when you resend it as part of your patch set.
Right, but I don't think Ibrahim needs those patches anymore,
because as you said FAN_RESTARTABLE_EVENTS do not require
a response id.
>
> Now to the content: Amir, this looks quite hacky to me and I think we can
> do better. How about:
>
> struct fanotify_perm_event {
> struct fanotify_event fae;
> const loff_t *ppos; /* optional file range info */
> size_t count;
> u32 response; /* userspace answer to the event */
> unsigned short state; /* state of the event */
> int fd; /* fd we passed to userspace for this event */
> union {
> struct fanotify_response_info_header hdr;
> struct fanotify_response_info_audit_rule audit_rule;
> };
> union {
> struct path path;
> struct {
> __kernel_fsid_t fsid;
> struct fanotify_info info;
> };
> };
> };
>
> This actually doesn't grow struct fanotify_perm_event and should make
> things more or less bussiness as usual.
Yeh, that's less hacky for sure.
My hacky patches were keeping the path alongside the variable fid,
but I agree that we can go for response_id for the pre-dir-access events.
However, unless it is urgent to Ibrahim, I am not going to pick this up before
the end of August..
Thanks,
Amir.
