]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
exportfs: support encoding non-decodeable file handles by default
authorAmir Goldstein <amir73il@gmail.com>
Mon, 23 Oct 2023 18:08:01 +0000 (21:08 +0300)
committerChristian Brauner <brauner@kernel.org>
Sat, 28 Oct 2023 14:16:18 +0000 (16:16 +0200)
commit64343119d7b80b4ee9ba7703390681608a17f2c5
tree0dc0cfd9b19f364ec46ce51a7aa1d383e2b9b091
parent41d1ddd2717c758b8606a66d57d2cc63b41373c0
exportfs: support encoding non-decodeable file handles by default

AT_HANDLE_FID was added as an API for name_to_handle_at() that request
the encoding of a file id, which is not intended to be decoded.

This file id is used by fanotify to describe objects in events.

So far, overlayfs is the only filesystem that supports encoding
non-decodeable file ids, by providing export_operations with an
->encode_fh() method and without a ->decode_fh() method.

Add support for encoding non-decodeable file ids to all the filesystems
that do not provide export_operations, by encoding a file id of type
FILEID_INO64_GEN from { i_ino, i_generation }.

A filesystem may that does not support NFS export, can opt-out of
encoding non-decodeable file ids for fanotify by defining an empty
export_operations struct (i.e. with a NULL ->encode_fh() method).

This allows the use of fanotify events with file ids on filesystems
like 9p which do not support NFS export to bring fanotify in feature
parity with inotify on those filesystems.

Note that fanotify also requires that the filesystems report a non-null
fsid.  Currently, many simple filesystems that have support for inotify
(e.g. debugfs, tracefs, sysfs) report a null fsid, so can still not be
used with fanotify in file id reporting mode.

Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Link: https://lore.kernel.org/r/20231023180801.2953446-5-amir73il@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
fs/exportfs/expfs.c
include/linux/exportfs.h