Thread (13 messages) 13 messages, 3 authors, 2023-10-25

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

From: Amir Goldstein <amir73il@gmail.com>
Date: 2023-10-18 18:35:47
Also in: linux-fsdevel

On Wed, Sep 20, 2023 at 7:36 PM Jan Kara [off-list ref] wrote:
On Wed 20-09-23 18:12:00, Amir Goldstein wrote:
quoted
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 think I get what you mean.
Pushed POC (only compile tested so far) to branch inode_fsid on my github [1]
and posted the patches for seamless support for non-decodable fid.

Let me know if that is what you meant.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/inode_fsid
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help