Add support for reading / writing to the exfat volume label from the
FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL ioctls.

Implemented in similar ways to other fs drivers, namely btrfs and ext4,
where the ioctls are performed on file inodes.

v2:
Fix endianness conversion as reported by kernel test robot
v1:
Link: https://lore.kernel.org/all/20250815171056.103751-1-ethan.ferguson@zetier.com/

Ethan Ferguson (1):
  exfat: Add support for FS_IOC_{GET,SET}FSLABEL
  exfat: Fix endian conversion

 fs/exfat/exfat_fs.h  |  2 +
 fs/exfat/exfat_raw.h |  6 +++
 fs/exfat/file.c      | 56 +++++++++++++++++++++++++
 fs/exfat/super.c     | 99 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 163 insertions(+)

-- 
2.50.1

On Sun, Aug 17, 2025 at 9:31 AM Ethan Ferguson
<ethan.ferguson@zetier.com> wrote:
>
> Add support for reading / writing to the exfat volume label from the
> FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL ioctls.
>
> Implemented in similar ways to other fs drivers, namely btrfs and ext4,
> where the ioctls are performed on file inodes.
We can load and store a volume label using tune.exfat in exfatprogs.
Is there any usage that requires this, even though there are utils
that can do it?

Thanks.
>
> v2:
> Fix endianness conversion as reported by kernel test robot
> v1:
> Link: https://lore.kernel.org/all/20250815171056.103751-1-ethan.ferguson@zetier.com/
>
> Ethan Ferguson (1):
>   exfat: Add support for FS_IOC_{GET,SET}FSLABEL
>   exfat: Fix endian conversion
>
>  fs/exfat/exfat_fs.h  |  2 +
>  fs/exfat/exfat_raw.h |  6 +++
>  fs/exfat/file.c      | 56 +++++++++++++++++++++++++
>  fs/exfat/super.c     | 99 ++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 163 insertions(+)
>
> --
> 2.50.1
>

On 8/17/25 08:30, Namjae Jeon wrote:
> On Sun, Aug 17, 2025 at 9:31 AM Ethan Ferguson
> <ethan.ferguson@zetier.com> wrote:
>>
>> Add support for reading / writing to the exfat volume label from the
>> FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL ioctls.
>>
>> Implemented in similar ways to other fs drivers, namely btrfs and ext4,
>> where the ioctls are performed on file inodes.
> We can load and store a volume label using tune.exfat in exfatprogs.
> Is there any usage that requires this, even though there are utils
> that can do it?
> 
> Thanks.
Both e2fsprogs and btrfs-progs now use the FS_IOC_{GET,SET}FSLABEL
ioctls to change the label on a mounted filesystem.

As for me, personally, I ran into this while developing on an
embedded device that does not have, and cannot have, exfatprogs.
Having this be a kernel feature would (I believe) bring the exfat driver
more in line with other fs drivers in the mainline tree.

Thank you for your consideration!

>>
>> v2:
>> Fix endianness conversion as reported by kernel test robot
>> v1:
>> Link: https://lore.kernel.org/all/20250815171056.103751-1-ethan.ferguson@zetier.com/
>>
>> Ethan Ferguson (1):
>>   exfat: Add support for FS_IOC_{GET,SET}FSLABEL
>>   exfat: Fix endian conversion
>>
>>  fs/exfat/exfat_fs.h  |  2 +
>>  fs/exfat/exfat_raw.h |  6 +++
>>  fs/exfat/file.c      | 56 +++++++++++++++++++++++++
>>  fs/exfat/super.c     | 99 ++++++++++++++++++++++++++++++++++++++++++++
>>  4 files changed, 163 insertions(+)
>>
>> --
>> 2.50.1
>>

On Sun, Aug 17, 2025 at 10:32:00AM -0400, Ethan Ferguson wrote:
> Both e2fsprogs and btrfs-progs now use the FS_IOC_{GET,SET}FSLABEL
> ioctls to change the label on a mounted filesystem.

Additionally userspace writes to blocks on mounted file systems are
dangerous.  They can easily corrupt data when racing with updates
performed by the kernel, and are impossible when the the
CONFIG_BLK_DEV_WRITE_MOUNTED config option is disabled.

On 8/18/25 01:52, Christoph Hellwig wrote:
> On Sun, Aug 17, 2025 at 10:32:00AM -0400, Ethan Ferguson wrote:
>> Both e2fsprogs and btrfs-progs now use the FS_IOC_{GET,SET}FSLABEL
>> ioctls to change the label on a mounted filesystem.
> 
> Additionally userspace writes to blocks on mounted file systems are
> dangerous.  They can easily corrupt data when racing with updates
> performed by the kernel, and are impossible when the the
> CONFIG_BLK_DEV_WRITE_MOUNTED config option is disabled.

That's fair. I took a look at how btrfs guards against this, it seems
as if they use mnt_want_write_file to guard against bad writes, and
only write to the in-memory superblock, and commit the transaction
afterwards. However, this (during my testing with
CONFIG_BLK_DEV_WRITE_MOUNTED both on and off) still results in an
immediate disk flush.

My changes from this thread also seem to work with
CONFIG_BLK_DEV_WRITE_MOUNTED both disabled and enabled.

Maybe an alternative would be to only write to sbi->volume_label (with
mutex guarding), and only flush to disk on exfat_put_super? And to use
mnt_want_write_file as well.

Unfortunately, given that I'm pretty new to kernel development, I
wouldn't know that the best way to approach this. Any thoughts, or
pointers in the right direction, would be appreciated.

Thank you for the feedback!

On Mon, Aug 18, 2025 at 01:49:11PM -0400, Ethan Ferguson wrote:
> That's fair. I took a look at how btrfs guards against this, it seems
> as if they use mnt_want_write_file to guard against bad writes, and
> only write to the in-memory superblock, and commit the transaction
> afterwards. However, this (during my testing with
> CONFIG_BLK_DEV_WRITE_MOUNTED both on and off) still results in an
> immediate disk flush.
> 
> My changes from this thread also seem to work with
> CONFIG_BLK_DEV_WRITE_MOUNTED both disabled and enabled.

What I meant to say is that we actually need your change to work with
CONFIG_BLK_DEV_WRITE_MOUNTED, as the current way in tunefs is broken,
even if that's something a few Linux file systems have historically
done.

> Maybe an alternative would be to only write to sbi->volume_label (with
> mutex guarding), and only flush to disk on exfat_put_super? And to use
> mnt_want_write_file as well.

I think your patch is fine as-is.  I've just been trying to give you
additional ammunition.