From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>,
Jeff Layton <jlayton@kernel.org>, Jan Kara <jack@suse.cz>,
Aleksa Sarai <cyphar@cyphar.com>,
Chuck Lever <chuck.lever@oracle.com>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v4 1/3] fs: prepare for "explicit connectable" file handles
Date: Mon, 14 Oct 2024 15:30:43 +0200 [thread overview]
Message-ID: <20241014133043.sucfbpsx4gnjvacb@quack3> (raw)
In-Reply-To: <20241011090023.655623-2-amir73il@gmail.com>
On Fri 11-10-24 11:00:21, Amir Goldstein wrote:
> We would like to use the high 16bit of the handle_type field to encode
> file handle traits, such as "connectable".
>
> In preparation for this change, make sure that filesystems do not return
> a handle_type value with upper bits set and that the open_by_handle_at(2)
> syscall rejects these handle types.
>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Looks good. Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/exportfs/expfs.c | 17 +++++++++++++++--
> fs/fhandle.c | 7 +++++++
> include/linux/exportfs.h | 11 +++++++++++
> 3 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
> index 4f2dd4ab4486..0c899cfba578 100644
> --- a/fs/exportfs/expfs.c
> +++ b/fs/exportfs/expfs.c
> @@ -382,14 +382,24 @@ int exportfs_encode_inode_fh(struct inode *inode, struct fid *fid,
> int *max_len, struct inode *parent, int flags)
> {
> const struct export_operations *nop = inode->i_sb->s_export_op;
> + enum fid_type type;
>
> if (!exportfs_can_encode_fh(nop, flags))
> return -EOPNOTSUPP;
>
> if (!nop && (flags & EXPORT_FH_FID))
> - return exportfs_encode_ino64_fid(inode, fid, max_len);
> + type = exportfs_encode_ino64_fid(inode, fid, max_len);
> + else
> + type = nop->encode_fh(inode, fid->raw, max_len, parent);
> +
> + if (type > 0 && FILEID_USER_FLAGS(type)) {
> + pr_warn_once("%s: unexpected fh type value 0x%x from fstype %s.\n",
> + __func__, type, inode->i_sb->s_type->name);
> + return -EINVAL;
> + }
> +
> + return type;
>
> - return nop->encode_fh(inode, fid->raw, max_len, parent);
> }
> EXPORT_SYMBOL_GPL(exportfs_encode_inode_fh);
>
> @@ -436,6 +446,9 @@ exportfs_decode_fh_raw(struct vfsmount *mnt, struct fid *fid, int fh_len,
> char nbuf[NAME_MAX+1];
> int err;
>
> + if (fileid_type < 0 || FILEID_USER_FLAGS(fileid_type))
> + return ERR_PTR(-EINVAL);
> +
> /*
> * Try to get any dentry for the given file handle from the filesystem.
> */
> diff --git a/fs/fhandle.c b/fs/fhandle.c
> index 82df28d45cd7..218511f38cbb 100644
> --- a/fs/fhandle.c
> +++ b/fs/fhandle.c
> @@ -307,6 +307,11 @@ static int handle_to_path(int mountdirfd, struct file_handle __user *ufh,
> retval = -EINVAL;
> goto out_path;
> }
> + if (f_handle.handle_type < 0 ||
> + FILEID_USER_FLAGS(f_handle.handle_type) & ~FILEID_VALID_USER_FLAGS) {
> + retval = -EINVAL;
> + goto out_path;
> + }
> handle = kmalloc(struct_size(handle, f_handle, f_handle.handle_bytes),
> GFP_KERNEL);
> if (!handle) {
> @@ -322,6 +327,8 @@ static int handle_to_path(int mountdirfd, struct file_handle __user *ufh,
> goto out_handle;
> }
>
> + /* Filesystem code should not be exposed to user flags */
> + handle->handle_type &= ~FILEID_USER_FLAGS_MASK;
> retval = do_handle_to_path(handle, path, &ctx);
>
> out_handle:
> diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
> index 893a1d21dc1c..5e14d4500a75 100644
> --- a/include/linux/exportfs.h
> +++ b/include/linux/exportfs.h
> @@ -160,6 +160,17 @@ struct fid {
> #define EXPORT_FH_FID 0x2 /* File handle may be non-decodeable */
> #define EXPORT_FH_DIR_ONLY 0x4 /* Only decode file handle for a directory */
>
> +/*
> + * Filesystems use only lower 8 bits of file_handle type for fid_type.
> + * name_to_handle_at() uses upper 16 bits of type as user flags to be
> + * interpreted by open_by_handle_at().
> + */
> +#define FILEID_USER_FLAGS_MASK 0xffff0000
> +#define FILEID_USER_FLAGS(type) ((type) & FILEID_USER_FLAGS_MASK)
> +
> +/* Flags supported in encoded handle_type that is exported to user */
> +#define FILEID_VALID_USER_FLAGS (0)
> +
> /**
> * struct export_operations - for nfsd to communicate with file systems
> * @encode_fh: encode a file handle fragment from a dentry
> --
> 2.34.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-10-14 13:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 9:00 [PATCH v4 0/3] API for exporting connectable file handles to userspace Amir Goldstein
2024-10-11 9:00 ` [PATCH v4 1/3] fs: prepare for "explicit connectable" file handles Amir Goldstein
2024-10-14 13:30 ` Jan Kara [this message]
2024-10-11 9:00 ` [PATCH v4 2/3] fs: name_to_handle_at() support " Amir Goldstein
2024-10-11 14:00 ` Jeff Layton
2024-10-11 14:14 ` Amir Goldstein
2024-10-11 14:18 ` Jeff Layton
2024-10-11 18:12 ` Amir Goldstein
2024-10-11 9:00 ` [PATCH v4 3/3] fs: open_by_handle_at() support for decoding " Amir Goldstein
2024-10-14 15:26 ` Jeff Layton
2024-10-11 14:04 ` [PATCH v4 0/3] API for exporting connectable file handles to userspace Jeff Layton
2024-10-11 14:24 ` Chuck Lever III
2024-10-11 18:22 ` Amir Goldstein
2024-10-11 18:40 ` Chuck Lever III
2024-10-14 8:55 ` Amir Goldstein
2024-10-14 14:52 ` Christian Brauner
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=20241014133043.sucfbpsx4gnjvacb@quack3 \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=cyphar@cyphar.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@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 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.