From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org
Subject: [RFC][PATCH 4/4] fanotify: support reporting non-decodeable file handles
Date: Tue, 25 Apr 2023 16:01:05 +0300 [thread overview]
Message-ID: <20230425130105.2606684-5-amir73il@gmail.com> (raw)
In-Reply-To: <20230425130105.2606684-1-amir73il@gmail.com>
fanotify users do not always need to decode the file handles reported
with FAN_REPORT_FID.
Relax the restriction that filesystem needs to support NFS export and
allow reporting file handles from filesystems that only support ecoding
unique file handles.
For such filesystems, users will have to use the AT_HANDLE_FID of
name_to_handle_at(2) if they want to compare the object in path to the
object fid reported in an event.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/notify/fanotify/fanotify.c | 4 ++--
fs/notify/fanotify/fanotify_user.c | 6 ++----
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index d1a49f5b6e6d..d2bbf1445a9e 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -380,7 +380,7 @@ static int fanotify_encode_fh_len(struct inode *inode)
if (!inode)
return 0;
- exportfs_encode_inode_fh(inode, NULL, &dwords, NULL, 0);
+ exportfs_encode_fid(inode, NULL, &dwords);
fh_len = dwords << 2;
/*
@@ -443,7 +443,7 @@ static int fanotify_encode_fh(struct fanotify_fh *fh, struct inode *inode,
}
dwords = fh_len >> 2;
- type = exportfs_encode_inode_fh(inode, buf, &dwords, NULL, 0);
+ type = exportfs_encode_fid(inode, buf, &dwords);
err = -EINVAL;
if (!type || type == FILEID_INVALID || fh_len != dwords << 2)
goto out_err;
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index 8f430bfad487..a5af84cbb30d 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -1586,11 +1586,9 @@ static int fanotify_test_fid(struct dentry *dentry)
* We need to make sure that the file system supports at least
* encoding a file handle so user can use name_to_handle_at() to
* compare fid returned with event to the file handle of watched
- * objects. However, name_to_handle_at() requires that the
- * filesystem also supports decoding file handles.
+ * objects, but it does not need to support decoding file handles.
*/
- if (!dentry->d_sb->s_export_op ||
- !dentry->d_sb->s_export_op->fh_to_dentry)
+ if (!dentry->d_sb->s_export_op)
return -EOPNOTSUPP;
return 0;
--
2.34.1
next prev parent reply other threads:[~2023-04-25 13:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-25 13:01 [RFC][PATCH 0/4] Prepare for supporting more filesystems with fanotify Amir Goldstein
2023-04-25 13:01 ` [RFC][PATCH 1/4] exportfs: change connectable argument to bit flags Amir Goldstein
2023-04-26 14:16 ` Chuck Lever
2023-04-25 13:01 ` [RFC][PATCH 2/4] exportfs: add explicit flag to request non-decodeable file handles Amir Goldstein
2023-04-26 14:18 ` Chuck Lever
2023-04-27 15:00 ` Jeff Layton
2023-04-27 15:13 ` Amir Goldstein
2023-04-25 13:01 ` [RFC][PATCH 3/4] exportfs: allow exporting non-decodeable file handles to userspace Amir Goldstein
2023-04-25 13:01 ` Amir Goldstein [this message]
2023-04-27 11:48 ` [RFC][PATCH 4/4] fanotify: support reporting non-decodeable file handles Jan Kara
2023-04-27 12:28 ` Amir Goldstein
2023-04-27 14:34 ` Amir Goldstein
2023-04-27 16:34 ` Jan Kara
2023-04-26 13:47 ` [RFC][PATCH 0/4] Prepare for supporting more filesystems with fanotify Chuck Lever
2023-04-27 4:57 ` Amir Goldstein
2023-04-27 15:13 ` Jeff Layton
2023-04-27 15:52 ` Amir Goldstein
2023-04-27 16:36 ` Jeff Layton
2023-04-27 19:11 ` Amir Goldstein
2023-04-27 19:26 ` Jeff Layton
2023-04-28 11:40 ` Jan Kara
2023-04-28 12:15 ` Jeff Layton
2023-04-28 12:31 ` Jan Kara
2023-04-28 12:33 ` Amir Goldstein
2023-04-29 14:45 ` Chuck Lever
2023-04-29 17:26 ` Amir Goldstein
2023-05-01 18:48 ` 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=20230425130105.2606684-5-amir73il@gmail.com \
--to=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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