All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-btrfs@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-ext4@vger.kernel.org,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Dave Chinner <dchinner@redhat.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	linux-fsdevel@vger.kernel.or
Subject: Re: [PATCH 2/6] fs: FS_IOC_GETUUID
Date: Tue, 6 Feb 2024 09:17:58 +1100	[thread overview]
Message-ID: <ZcFelmKPb374aebH@dread.disaster.area> (raw)
In-Reply-To: <20240205200529.546646-3-kent.overstreet@linux.dev>

On Mon, Feb 05, 2024 at 03:05:13PM -0500, Kent Overstreet wrote:
> Add a new generic ioctls for querying the filesystem UUID.
> 
> These are lifted versions of the ext4 ioctls, with one change: we're not
> using a flexible array member, because UUIDs will never be more than 16
> bytes.
> 
> This patch adds a generic implementation of FS_IOC_GETFSUUID, which
> reads from super_block->s_uuid; FS_IOC_SETFSUUID is left for individual
> filesystems to implement.
> 
> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
> 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: linux-fsdevel@vger.kernel.or
> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
> ---
>  fs/ioctl.c              | 16 ++++++++++++++++
>  include/uapi/linux/fs.h | 16 ++++++++++++++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 76cf22ac97d7..858801060408 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -763,6 +763,19 @@ static int ioctl_fssetxattr(struct file *file, void __user *argp)
>  	return err;
>  }
>  
> +static int ioctl_getfsuuid(struct file *file, void __user *argp)
> +{
> +	struct super_block *sb = file_inode(file)->i_sb;
> +
> +	if (WARN_ON(sb->s_uuid_len > sizeof(sb->s_uuid)))
> +		sb->s_uuid_len = sizeof(sb->s_uuid);

A "get"/read only ioctl should not be change superblock fields -
this is not the place for enforcing superblock filed constraints.
Make a helper function super_set_uuid(sb, uuid, uuid_len) for the
filesystems to call that does all the validity checking and then
sets the superblock fields appropriately.

> +
> +	struct fsuuid2 u = { .fsu_len = sb->s_uuid_len, };
> +	memcpy(&u.fsu_uuid[0], &sb->s_uuid, sb->s_uuid_len);

	if (!u.fsu_len)
		return -ENOENT;
	memcpy(&u.fsu_uuid[0], &sb->s_uuid, u.fsu_len);

> +
> +	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.
> @@ -845,6 +858,9 @@ static int do_vfs_ioctl(struct file *filp, unsigned int fd,
>  	case FS_IOC_FSSETXATTR:
>  		return ioctl_fssetxattr(filp, argp);
>  
> +	case FS_IOC_GETFSUUID:
> +		return ioctl_getfsuuid(filp, argp);
> +
>  	default:
>  		if (S_ISREG(inode->i_mode))
>  			return file_ioctl(filp, cmd, argp);
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index 48ad69f7722e..0389fea87db5 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -64,6 +64,20 @@ struct fstrim_range {
>  	__u64 minlen;
>  };
>  
> +/*
> + * We include a length field because some filesystems (vfat) have an identifier
> + * that we do want to expose as a UUID, but doesn't have the standard length.
> + *
> + * We use a fixed size buffer beacuse this interface will, by fiat, never
> + * support "UUIDs" longer than 16 bytes; we don't want to force all downstream
> + * users to have to deal with that.
> + */
> +struct fsuuid2 {
> +	__u32       fsu_len;
> +	__u32       fsu_flags;
> +	__u8        fsu_uuid[16];
> +};

Nobody in userspace will care that this is "version 2" of the ext4
ioctl. I'd just name it "fs_uuid" as though the ext4 version didn't
ever exist.

> +
>  /* extent-same (dedupe) ioctls; these MUST match the btrfs ioctl definitions */
>  #define FILE_DEDUPE_RANGE_SAME		0
>  #define FILE_DEDUPE_RANGE_DIFFERS	1
> @@ -215,6 +229,8 @@ struct fsxattr {
>  #define FS_IOC_FSSETXATTR		_IOW('X', 32, struct fsxattr)
>  #define FS_IOC_GETFSLABEL		_IOR(0x94, 49, char[FSLABEL_MAX])
>  #define FS_IOC_SETFSLABEL		_IOW(0x94, 50, char[FSLABEL_MAX])
> +#define FS_IOC_GETFSUUID		_IOR(0x94, 51, struct fsuuid2)
> +#define FS_IOC_SETFSUUID		_IOW(0x94, 52, struct fsuuid2)

0x94 is the btrfs ioctl space, not the VFS space - why did you
choose that? That said, what is the VFS ioctl space identifier? 'v',
perhaps?

-Dave.

-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2024-02-05 22:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-05 20:05 [PATCH 0/6] filesystem visibility ioctls Kent Overstreet
2024-02-05 20:05 ` [PATCH 1/6] fs: super_block->s_uuid_len Kent Overstreet
2024-02-05 21:58   ` Dave Chinner
2024-02-05 22:56     ` Kent Overstreet
2024-02-05 20:05 ` [PATCH 2/6] fs: FS_IOC_GETUUID Kent Overstreet
2024-02-05 22:17   ` Dave Chinner [this message]
2024-02-05 22:49     ` Kent Overstreet
2024-02-05 23:59       ` Darrick J. Wong
2024-02-06  8:24       ` Amir Goldstein
2024-02-06  9:00         ` Kent Overstreet
2024-02-05 20:05 ` [PATCH 3/6] fat: Hook up sb->s_uuid Kent Overstreet
2024-02-05 20:05 ` [PATCH 4/6] fs: FS_IOC_GETSYSFSNAME Kent Overstreet
2024-02-05 22:27   ` Darrick J. Wong
2024-02-05 22:43     ` Kent Overstreet
2024-02-06  1:39       ` David Sterba
2024-02-06  4:20         ` Randy Dunlap
2024-02-06  4:33           ` Kent Overstreet
2024-02-06  5:08             ` Darrick J. Wong
2024-02-06  5:13               ` Kent Overstreet
2024-02-05 20:05 ` [PATCH 5/6] xfs: add support for FS_IOC_GETSYSFSNAME Kent Overstreet
2024-02-05 20:05 ` [PATCH 6/6] bcachefs: " Kent Overstreet
2024-02-06 16:22 ` [PATCH 0/6] filesystem visibility ioctls 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=ZcFelmKPb374aebH@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=brauner@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.or \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@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 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.