Thread (11 messages) 11 messages, 4 authors, 2022-07-20

Re: [PATCH v4] Add ioctls to get/set the ext4 superblock uuid.

flat view

From: Matthew Wilcox <willy@infradead.org>
Date: 2022-07-20 19:09:12
Also in: linux-ext4, linux-fsdevel

On Wed, Jul 20, 2022 at 11:47:08AM -0700, Darrick J. Wong wrote:
On Wed, Jul 20, 2022 at 07:27:02PM +0100, Matthew Wilcox wrote:
quoted
On Wed, Jul 20, 2022 at 02:00:25PM -0400, Theodore Ts'o wrote:
quoted
On Wed, Jul 20, 2022 at 03:11:21PM +0100, Matthew Wilcox wrote:
quoted
Uhhh.  So what are the semantics of len?  That is, on SET, what does
a filesystem do if userspace says "Here's 8 bytes" but the filesystem
usually uses 16 bytes?  What does the same filesystem do if userspace
offers it 32 bytes?  If the answer is "returns -EINVAL", how does
userspace discover what size of volume ID is acceptable to a particular
filesystem?

And then, on GET, does 'len' just mean "here's the length of the buffer,
put however much will fit into it"?  Should filesystems update it to
inform userspace how much was transferred?
What I'd suggest is that for GET, the length field when called should
be the length of the buffer, and if the length is too small, we should
return some error --- probably EINVAL or ENOSPC.  If the buffer size
length is larger than what is needed, having the file system update it
with the size of the UUID that was returned.
I'd suggest something different -- calling the getfsuuid ioctl with a
null argument should return the filesystem's volid/uuid size as the
return value.  If userspace supplies a non-null argument, then fsu_len
has to match the filesystem's volid/uuid size or else you get EINVAL.
Or userspace passes in 0 for the len and the filesystem returns -EINVAL
and sets ->len to what the valid size would be?  There's a few ways of
solving this.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help