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.