Re: [PATCH v3 04/13] fanotify: define the structures to report a unique file identifier

[Amir Goldstein <amir73il@gmail.com>]

> > The issue is that fill_event_metadata() function fills a fixed size header
> > and later copy_event_to_user() copies that header to user and then
> > copies the variable sized fid to user, so this is not the place to "store"
> > fid, but I will work on readability of this code.
>
> Aha, I see. Thanks for your patience with me :). So then how about just
> folding fill_event_metadata() into copy_event_to_user() (as a preparatory
> patch). It is relatively small function, has a single call site and with
> FID changes the distinction isn't so clear anymore...
>

Sure. While you are here, before I start reworking, wanted to run by you
a few minor suggestions:

struct fanotify_event_info_fid {
        struct fanotify_event_info_header hdr;
        ....

Seems more appropriate name than the shorter fanotify_event_fid name
that you suggested.

It bothers me a bit not to use struct file_handle in the definition,
but I don't with to start moving struct file_handle into uapi.
I am a bit lost trying to understand which uapi include file I need
to include in fanotify.h if I want to use it. fcntl.h?

I am going to add a separate internal struct for storing fid in event
(either embedded of allocated) because I am going to make it more compact
(similar to struct ovl_fh)

struct fanotify_fid {
        __kernel_fsid_t fsid;
        u8 handle_bytes;
        u8 handle_type;
        u16 pad;
        unsigned char f_handle[0];
};

Will let you know when I have something ready.

AFAICT, this rework should not affect the rest of the patches in the
series (i.e. cached fsid
and dirent events), so if you have time, you don't need to wait on my
rework to continue
review of v3.

Thanks,
Amir.