lkml.org 
[lkml]   [2019]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL
Date

> On Dec 28, 2019, at 7:36 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
>
> Hello!
>
> I see that you have introduced in commit 62750d0 two new IOCTLs for
> filesyetems: FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL.
>
> I would like to ask, are these two new ioctls mean to be generic way for
> userspace to get or set fs label independently of which filesystem is
> used? Or are they only for btrfs?
>
> Because I was not able to find any documentation for it, what is format
> of passed buffer... null-term string? fixed-length? and in which
> encoding? utf-8? latin1? utf-16? or filesystem dependent?

It seems that SETFSLABEL is supported by BtrFS and XFS, and GETFSLABEL
also by GFS2. We were just discussing recently about adding it to ext4,
so if you wanted to submit a patch for that it would be welcome.

It looks like the label is a NUL-terminated string, up to the length
allowed by the various filesystems. That said, it seems like a bit of
a bug that the kernel will return -EFAULT if a string shorter than the
maximum size is supplied (256 chars for btrfs).

The copy_{to,from}_user() function will (I think) return the number of
bytes remaining to be copied, so IMHO it would make sense that this is
compared to the string length of the label, and not return -EFAULT if
the buffer is large enough to hold the actual label. Otherwise, the
caller has to magically know the maximum label size that is returned
from any filesystem and/or allocate specific buffer sizes for different
filesystem types, which makes it not very useful as a generic interface.


Cheers, Andreas





[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2019-12-28 20:15    [W:0.055 / U:21.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site