On Thu, Jul 16, 2020 at 3:44 PM Jan Kara <jack@xxxxxxx> wrote:
>
> On Thu 16-07-20 11:42:18, Amir Goldstein wrote:
> > The fanotify_fh struct has an inline buffer of size 12 which is enough
> > to store the most common local filesystem file handles (e.g. ext4, xfs).
> > For file handles that do not fit in the inline buffer (e.g. btrfs), an
> > external buffer is allocated to store the file handle.
> >
> > When allocating a variable size fanotify_name_event, there is no point
> > in allocating also an external fh buffer when file handle does not fit
> > in the inline buffer.
> >
> > Check required size for encoding fh, preallocate an event buffer
> > sufficient to contain both file handle and name and store the name after
> > the file handle.
> >
> > At this time, when not reporting name in event, we still allocate
> > the fixed size fanotify_fid_event and an external buffer for large
> > file handles, but fanotify_alloc_name_event() has already been prepared
> > to accept a NULL file_name.
> >
> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>
> When reading this, I've got one cleanup idea for later: For FID events, we
> could now easily check fh len in fanotify_alloc_fid_event(). If it fits in
> inline size, allocate the event from kmem cache, if it does not, allocate
> appropriately sized event from kmalloc(). Similarly when freeing event we
> could check fh len to determine how to free the event. This way we can
> completely get rid of the external buffer code, somewhat simplify all
> the fh handling, remove the alignment restrictions on fanotify_fh and
> fanotify_info...
>
OK. Note that the f_handle buffer passed to filesystems is expected to be
aligned anyway, although for encoding it may be less important, see:
cbe7fba8edfc ("ovl: make sure that real fid is 32bit aligned in memory")
Thanks,
Amir.
