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 <[email protected]>
---
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);
s->s_shrink = shrinker_alloc(SHRINKER_NUMA_AWARE | SHRINKER_MEMCG_AWARE,
"sb-%s", type->name);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index ed5966a70495..ff41ea6c3a9c 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1257,6 +1257,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 */
unsigned int s_max_links;
--
2.43.0
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 <[email protected]>
> ---
> 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
[email protected]
On Tue, Feb 06, 2024 at 08:58:49AM +1100, Dave Chinner wrote:
> 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 <[email protected]>
> > ---
> > 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...
*nod* this all falls out of your super_set_uuid() suggestion