From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@kernel.org>,
Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [RFC][PATCH] fanotify: Enable FAN_REPORT_FID on more filesystem types
Date: Wed, 20 Sep 2023 18:36:34 +0200 [thread overview]
Message-ID: <20230920163634.5agdx523uv7m2qtf@quack3> (raw)
In-Reply-To: <CAOQ4uxj-5n3ja+22Qv4H27wEGn=eAdE1JNRBSxS3TgdEr7b75A@mail.gmail.com>
On Wed 20-09-23 18:12:00, Amir Goldstein wrote:
> On Wed, Sep 20, 2023 at 4:48 PM Jan Kara <jack@suse.cz> 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@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-09-20 16:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 12:40 [RFC][PATCH] fanotify: Enable FAN_REPORT_FID on more filesystem types Amir Goldstein
2023-04-12 18:43 ` Jan Kara
2023-04-13 9:25 ` Amir Goldstein
2023-04-17 16:27 ` Jan Kara
2023-09-20 8:26 ` Amir Goldstein
2023-09-20 10:27 ` Jeff Layton
2023-09-20 11:04 ` Jan Kara
2023-09-20 12:41 ` Amir Goldstein
2023-09-20 13:48 ` Jan Kara
2023-09-20 15:12 ` Amir Goldstein
2023-09-20 16:36 ` Jan Kara [this message]
2023-10-18 18:35 ` Amir Goldstein
2023-10-25 14:11 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230920163634.5agdx523uv7m2qtf@quack3 \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).