[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZcFaGRV08WQOxCzb@dread.disaster.area>
Date: Tue, 6 Feb 2024 08:58:49 +1100
From: Dave Chinner <david@...morbit.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/6] fs: super_block->s_uuid_len
On Mon, Feb 05, 2024 at 03:05:12PM -0500, Kent Overstreet wrote:
> Some weird old filesytems have UUID-like things that we wish to expose
> as UUIDs, but are smaller; add a length field so that the new
> FS_IOC_(GET|SET)UUID ioctls can handle them in generic code.
>
> Signed-off-by: Kent Overstreet <kent.overstreet@...ux.dev>
> ---
> fs/super.c | 1 +
> include/linux/fs.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/fs/super.c b/fs/super.c
> index d35e85295489..ed688d2a58a7 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -375,6 +375,7 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags,
> s->s_time_gran = 1000000000;
> s->s_time_min = TIME64_MIN;
> s->s_time_max = TIME64_MAX;
> + s->s_uuid_len = sizeof(s->s_uuid);
So if the filesystem doesn't copy a uuid into sb->s_uuid, then we
allow those 16 bytes to be pulled from userspace?
Shouldn't this only get set when the filesystem copies it's uuid
to the superblock?
And then in the get uuid ioctl, if s_uuid_len is zero we can return
-ENOENT to indicate the filesystem doesn't have a UUID, rather that
require userspace to determine a filesystem doesn't have a valid
UUID somehow...
-Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists