Re: [RFC][PATCH 0/4] Prepare for supporting more filesystems with fanotify

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 27, 2023 at 6:13 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>
> On Tue, 2023-04-25 at 16:01 +0300, Amir Goldstein wrote:
> > Jan,
> >
> > Following up on the FAN_REPORT_ANY_FID proposal [1], here is a shot at an
> > alternative proposal to seamlessly support more filesystems.
> >
> > While fanotify relaxes the requirements for filesystems to support
> > reporting fid to require only the ->encode_fh() operation, there are
> > currently no new filesystems that meet the relaxed requirements.
> >
> > I will shortly post patches that allow overlayfs to meet the new
> > requirements with default overlay configurations.
> >
> > The overlay and vfs/fanotify patch sets are completely independent.
> > The are both available on my github branch [2] and there is a simple
> > LTP test variant that tests reporting fid from overlayfs [3], which
> > also demonstrates the minor UAPI change of name_to_handle_at(2) for
> > requesting a non-decodeable file handle by userspace.
> >
> > Thanks,
> > Amir.
> >
> > [1] https://lore.kernel.org/linux-fsdevel/20230417162721.ouzs33oh6mb7vtft@quack3/
> > [2] https://github.com/amir73il/linux/commits/exportfs_encode_fid
> > [3] https://github.com/amir73il/ltp/commits/exportfs_encode_fid
> >
> > Amir Goldstein (4):
> >   exportfs: change connectable argument to bit flags
> >   exportfs: add explicit flag to request non-decodeable file handles
> >   exportfs: allow exporting non-decodeable file handles to userspace
> >   fanotify: support reporting non-decodeable file handles
> >
> >  Documentation/filesystems/nfs/exporting.rst |  4 +--
> >  fs/exportfs/expfs.c                         | 29 ++++++++++++++++++---
> >  fs/fhandle.c                                | 20 ++++++++------
> >  fs/nfsd/nfsfh.c                             |  5 ++--
> >  fs/notify/fanotify/fanotify.c               |  4 +--
> >  fs/notify/fanotify/fanotify_user.c          |  6 ++---
> >  fs/notify/fdinfo.c                          |  2 +-
> >  include/linux/exportfs.h                    | 18 ++++++++++---
> >  include/uapi/linux/fcntl.h                  |  5 ++++
> >  9 files changed, 67 insertions(+), 26 deletions(-)
> >
>
> This set looks fairly benign to me, so ACK on the general concept.

Thanks!

>
> I am starting to dislike how the AT_* flags are turning into a bunch of
> flags that only have meanings on certain syscalls. I don't see a cleaner
> way to handle it though.

Yeh, it's not great.

There is also a way to extend the existing API with:

Perhstruct file_handle {
        unsigned int handle_bytes:8;
        unsigned int handle_flags:24;
        int handle_type;
        unsigned char f_handle[];
};

AFAICT, this is guaranteed to be backward compat
with old kernels and old applications.

It also may not be a bad idea that the handle_flags could
be used to request specific fh properties (FID) and can also
describe the properties of the returned fh (i.e. non-decodeable)
that could also be respected by open_by_handle_at().

For backward compact, kernel will only set handle_flags in
response if new flags were set in the request.

Do you consider this extension better than AT_HANDLE_FID
or worse? At least it is an API change that is contained within the
exportfs subsystem, without polluting the AT_ flags global namespace.

Thanks,
Amir.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux