From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>,
Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
David Sterba <dsterba@suse.com>,
Luis de Bethencourt <luisbg@kernel.org>,
Salah Triki <salah.triki@gmail.com>, Gao Xiang <xiang@kernel.org>,
Chao Yu <chao@kernel.org>, Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jaegeuk Kim <jaegeuk@kernel.org>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Dave Kleikamp <shaggy@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Richard Weinberger <richard@nod.at>,
Anton Altaparmakov <anton@tuxera.com>,
Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
Steve French <sfrench@samba.org>,
Phillip Lougher <phillip@squashfs.org.uk>,
Evgeniy Dushistov <dushistov@mail.ru>
Subject: Re: [PATCH 3/5] exportfs: make ->encode_fh() a mandatory method for NFS export
Date: Thu, 19 Oct 2023 16:40:26 +0200 [thread overview]
Message-ID: <20231019144026.2qypsldg5hlca5zc@quack3> (raw)
In-Reply-To: <20231018100000.2453965-4-amir73il@gmail.com>
On Wed 18-10-23 12:59:58, Amir Goldstein wrote:
> export_operations ->encode_fh() no longer has a default implementation to
> encode FILEID_INO32_GEN* file handles.
>
> Rename the default helper for encoding FILEID_INO32_GEN* file handles to
> generic_encode_ino32_fh() and convert the filesystems that used the
> default implementation to use the generic helper explicitly.
>
> This is a step towards allowing filesystems to encode non-decodeable file
> handles for fanotify without having to implement any export_operations.
>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Just one typo cleanup. Also I agree we need a "nop" variant of
generic_encode_ino32_fh() or move this to fs/libfs.c like e.g.
generic_fh_to_dentry().
> diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
> index 4d05b9862451..197ef78a5014 100644
> --- a/Documentation/filesystems/porting.rst
> +++ b/Documentation/filesystems/porting.rst
> @@ -1045,3 +1045,12 @@ filesystem type is now moved to a later point when the devices are closed:
> As this is a VFS level change it has no practical consequences for filesystems
> other than that all of them must use one of the provided kill_litter_super(),
> kill_anon_super(), or kill_block_super() helpers.
> +
> +---
> +
> +**mandatory**
> +
> +export_operations ->encode_fh() no longer has a default implementation to
> +encode FILEID_INO32_GEN* file handles.
> +Fillesystems that used the default implementation may use the generic helper
^^^ Filesystems
> +generic_encode_ino32_fh() explicitly.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-10-19 14:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 9:59 [PATCH 0/5] Support more filesystems with FAN_REPORT_FID Amir Goldstein
2023-10-18 9:59 ` [PATCH 1/5] fanotify: limit reporting of event with non-decodeable file handles Amir Goldstein
2023-10-19 14:22 ` Jan Kara
2023-10-18 9:59 ` [PATCH 2/5] exportfs: add helpers to check if filesystem can encode/decode " Amir Goldstein
2023-10-18 14:15 ` Jeff Layton
2023-10-19 14:23 ` Jan Kara
2023-10-18 9:59 ` [PATCH 3/5] exportfs: make ->encode_fh() a mandatory method for NFS export Amir Goldstein
2023-10-18 14:16 ` Jeff Layton
2023-10-18 14:53 ` Dave Kleikamp
2023-10-18 15:24 ` Amir Goldstein
2023-10-18 15:18 ` Chuck Lever
2023-10-18 15:26 ` Amir Goldstein
2023-10-18 15:36 ` Chuck Lever
2023-10-19 14:40 ` Jan Kara [this message]
2023-10-19 15:22 ` Amir Goldstein
2023-10-21 16:48 ` kernel test robot
2023-10-22 3:11 ` kernel test robot
2023-10-18 9:59 ` [PATCH 4/5] exportfs: define FILEID_INO64_GEN* file handle types Amir Goldstein
2023-10-18 14:18 ` Jeff Layton
2023-10-19 14:41 ` Jan Kara
2023-10-18 10:00 ` [PATCH 5/5] exportfs: support encoding non-decodeable file handles by default Amir Goldstein
2023-10-18 14:28 ` Jeff Layton
2023-10-18 15:11 ` Amir Goldstein
2023-10-18 15:27 ` Chuck Lever
2023-10-18 17:19 ` Amir Goldstein
2023-10-23 13:55 ` Amir Goldstein
2023-10-23 16:33 ` Jan Kara
2023-10-23 16:44 ` 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=20231019144026.2qypsldg5hlca5zc@quack3 \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=amir73il@gmail.com \
--cc=anton@tuxera.com \
--cc=brauner@kernel.org \
--cc=chao@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dsterba@suse.com \
--cc=dushistov@mail.ru \
--cc=dwmw2@infradead.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jaegeuk@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=luisbg@kernel.org \
--cc=phillip@squashfs.org.uk \
--cc=richard@nod.at \
--cc=salah.triki@gmail.com \
--cc=sfrench@samba.org \
--cc=shaggy@kernel.org \
--cc=tytso@mit.edu \
--cc=xiang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.