On Wed 20-09-23 18:12:00, Amir Goldstein wrote:

On Wed, Sep 20, 2023 at 4:48 PM Jan Kara [off-list ref] wrote:

quoted

quoted

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 [off-list ref]
SUSE Labs, CR