Re: [RFC][PATCH] fanotify: Enable FAN_REPORT_FID on more filesystem types

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

 



On Wed 20-09-23 18:12:00, Amir Goldstein wrote:
> On Wed, Sep 20, 2023 at 4:48 PM Jan Kara <jack@xxxxxxx> wrote:
> > > If users had a flag to statfs() to request the "btrfs root volume fsid",
> > > then fanotify could also report the root fsid and everyone will be happy
> > > because the btrfs file handle already contains the subvolume root
> > > object id (FILEID_BTRFS_WITH_PARENT_ROOT), but that is not
> > > what users get for statfs() and that is not what fanotify documentation
> > > says about how to query fsid.
> > >
> > > We could report the subvolume fsid for marked inode/mount
> > > that is not a problem - we just cache the subvol fsid in inode/mount
> > > connector, but that fsid will be inconsistent with the fsid in the sb
> > > connector, so the same object (in subvolume) can get events
> > > with different fsid (e.g. if one event is in mask of sb and another
> > > event is in mask of inode).
> >
> > Yes. I'm sorry I didn't describe all the details. My idea was to report
> > even on a dentry with the fsid statfs(2) would return on it. We don't want
> > to call dentry_statfs() on each event (it's costly and we don't always have
> > the dentry available) but we can have a special callback into the
> > filesystem to get us just the fsid (which is very cheap) and call *that* on
> > the inode on which the event happens to get fsid for the event. So yes, the
> > sb mark would be returning events with different fsids for btrfs. Or we
> > could compare the obtained fsid with the one in the root volume and ignore
> > the event if they mismatch (that would be more like the different subvolume
> > => different filesystem point of view and would require some more work on
> > fanotify side to remember fsid in the sb mark and not in the sb connector).
> >
> 
> It sounds like a big project.

Actually it should be pretty simple as I imagine it. Maybe I can quickly
hack a POC.

> I am not sure it is really needed.
>
> On second thought, maybe getting different events on the
> same subvol with different fsid is not that bad, because for
> btrfs, it is possible to resolve the path of an fid in subvol
> from either the root mount or the subvol mount.
> IOW, subvol_fsid+fid and root_fsid+fid are two ways to
> describe the same unique object.
> 
> Remember that we have two use cases for fsid+fid:
> 1. (unpriv/priv) User queries fsid+fid, sets an inode mark on path,
>     stores fsid+fid<->path in a map to match events to path later
> 2. (priv-only) User queries fsid, sets a sb/mount mark on path,
>     stores fsid<->path to match event to mntfd and
>     resolves path by handle from mntfd+fid

You're right that for open_by_handle_at() the fsid is actually only good
for getting *any* path on the superblock where file handle can be used so
any of the fsids provided by btrfs is OK. What will be a slight catch is
that if you would be using name_to_handle_at() to match what you've got
from fanotify you will never be able to identify some fids. I'm not sure
how serious that would be...

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR



[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