From: Dave Chinner <david@fromorbit.com>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: brauner@kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, Jan Kara <jack@suse.cz>,
Dave Chinner <dchinner@redhat.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Theodore Ts'o <tytso@mit.edu>, Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH v2 5/7] fs: FS_IOC_GETSYSFSNAME
Date: Wed, 7 Feb 2024 09:26:40 +1100 [thread overview]
Message-ID: <ZcKyIMPy1D1o5Yla@dread.disaster.area> (raw)
In-Reply-To: <20240206201858.952303-6-kent.overstreet@linux.dev>
On Tue, Feb 06, 2024 at 03:18:53PM -0500, Kent Overstreet wrote:
> Add a new ioctl for getting the sysfs name of a filesystem - the path
> under /sys/fs.
>
> This is going to let us standardize exporting data from sysfs across
> filesystems, e.g. time stats.
>
> The returned path will always be of the form "$FSTYP/$SYSFS_IDENTIFIER",
> where the sysfs identifier may be a UUID (for bcachefs) or a device name
> (xfs).
>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Dave Chinner <dchinner@redhat.com>
> Cc: "Darrick J. Wong" <djwong@kernel.org>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
> ---
> fs/ioctl.c | 17 +++++++++++++++++
> include/linux/fs.h | 1 +
> include/uapi/linux/fs.h | 10 ++++++++++
> 3 files changed, 28 insertions(+)
>
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 046c30294a82..7c37765bd04e 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -776,6 +776,20 @@ static int ioctl_getfsuuid(struct file *file, void __user *argp)
> return copy_to_user(argp, &u, sizeof(u)) ? -EFAULT : 0;
> }
>
> +static int ioctl_get_fs_sysfs_path(struct file *file, void __user *argp)
> +{
> + struct super_block *sb = file_inode(file)->i_sb;
> +
> + if (!strlen(sb->s_sysfs_name))
> + return -ENOIOCTLCMD;
This relies on the kernel developers getting string termination
right and not overflowing buffers.
We can do better, I think, and I suspect that starts with a
super_set_sysfs_name() helper....
> + struct fssysfspath u = {};
Variable names that look like the cat just walked over the keyboard
are difficult to read. Please use some separators here!
Also, same comment as previous about mixing code and declarations.
> +
> + snprintf(u.name, sizeof(u.name), "%s/%s", sb->s_type->name, sb->s_sysfs_name);
What happens if the combined path overflows the fssysfspath
buffer?
> +
> + return copy_to_user(argp, &u, sizeof(u)) ? -EFAULT : 0;
> +}
> +
> /*
> * do_vfs_ioctl() is not for drivers and not intended to be EXPORT_SYMBOL()'d.
> * It's just a simple helper for sys_ioctl and compat_sys_ioctl.
> @@ -861,6 +875,9 @@ static int do_vfs_ioctl(struct file *filp, unsigned int fd,
> case FS_IOC_GETFSUUID:
> return ioctl_getfsuuid(filp, argp);
>
> + case FS_IOC_GETFSSYSFSPATH:
> + return ioctl_get_fs_sysfs_path(filp, argp);
> +
> default:
> if (S_ISREG(inode->i_mode))
> return file_ioctl(filp, cmd, argp);
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index acdc56987cb1..b96c1d009718 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1258,6 +1258,7 @@ struct super_block {
> char s_id[32]; /* Informational name */
> uuid_t s_uuid; /* UUID */
> u8 s_uuid_len; /* Default 16, possibly smaller for weird filesystems */
> + char s_sysfs_name[UUID_STRING_LEN + 1];
Can we just kstrdup() the sysfs name and keep a {ptr, len} pair
in the sb for this? Then we can treat them as an opaque identifier
that isn't actually a string, and we don't have to make up some
arbitrary maximum name size, either.
> unsigned int s_max_links;
>
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index 16a6ecadfd8d..c0f7bd4b6350 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -77,6 +77,10 @@ struct fsuuid2 {
> __u8 uuid[16];
> };
>
> +struct fssysfspath {
> + __u8 name[128];
> +};
Undocumented magic number in a UAPI. Why was this chosen?
IMO, we shouldn't be returning strings that require the the kernel
to place NULLs correctly and for the caller to detect said NULLs to
determine their length, so something like:
struct fs_sysfs_path {
__u32 name_len;
__u8 name[NAME_MAX];
};
Seems better to me...
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2024-02-06 22:26 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 20:18 [PATCH v2 0/7] filesystem visibililty ioctls Kent Overstreet
2024-02-06 20:18 ` [PATCH v2 1/7] fs: super_set_uuid() Kent Overstreet
2024-02-06 21:45 ` Dave Chinner
2024-02-06 20:18 ` [PATCH v2 2/7] overlayfs: Convert to super_set_uuid() Kent Overstreet
2024-02-06 21:48 ` Dave Chinner
2024-02-07 6:19 ` Amir Goldstein
2024-02-06 20:18 ` [PATCH v2 3/7] fs: FS_IOC_GETUUID Kent Overstreet
2024-02-06 20:29 ` Randy Dunlap
2024-02-06 22:01 ` Dave Chinner
2024-02-06 22:37 ` Kent Overstreet
2024-02-07 0:20 ` Dave Chinner
2024-02-07 13:05 ` Brian Foster
2024-02-08 21:57 ` Kent Overstreet
2024-02-12 12:47 ` Brian Foster
2024-02-12 13:39 ` Kent Overstreet
2024-02-12 16:53 ` Brian Foster
2024-02-06 20:18 ` [PATCH v2 4/7] fat: Hook up sb->s_uuid Kent Overstreet
2024-02-06 20:18 ` [PATCH v2 5/7] fs: FS_IOC_GETSYSFSNAME Kent Overstreet
2024-02-06 22:26 ` Dave Chinner [this message]
2024-02-07 0:52 ` Kent Overstreet
2024-02-06 20:18 ` [PATCH v2 6/7] xfs: add support for FS_IOC_GETSYSFSNAME Kent Overstreet
2024-02-06 20:18 ` [PATCH v2 7/7] bcachefs: " Kent Overstreet
2024-02-07 1:47 ` [PATCH v2 0/7] filesystem visibililty ioctls Eric Biggers
2024-02-07 2:09 ` Kent Overstreet
2024-02-07 17:40 ` Theodore Ts'o
2024-02-07 20:26 ` Kent Overstreet
2024-02-08 9:01 ` Christian Brauner
2024-02-12 22:47 ` Theodore Ts'o
2024-02-12 23:24 ` Kent Overstreet
2024-02-08 9:48 ` Christian Brauner
2024-02-08 18:16 ` Kent Overstreet
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=ZcKyIMPy1D1o5Yla@dread.disaster.area \
--to=david@fromorbit.com \
--cc=brauner@kernel.org \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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