Re: [RFC] vfs_parse_fs_string() calling conventions change (was Re: [PATCH v2 17/35] sanitize handling of long-term internal mounts)

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Jun 30, 2025 at 04:19:53PM +0100, David Howells wrote:
> Al Viro <viro@zeniv.linux.org.uk> wrote:
> 
> > Frankly, looking at that stuff...  I wonder if we should add
> > vfs_parse_fs_qstr() for "comes with length" variant and lose the length
> > argument of vfs_parse_fs_string().
> 
> Um - why use a qstr?  Does using a qstr actually gain anything much?  Why not
> just, say:
> 
> extern int vfs_parse_fs_str_len(struct fs_context *fc, const char *key,
> 				const char *value, size_t v_size);
> static inline int vfs_parse_fs_string(struct fs_context *fc, const char *key,
> 			       const char *value)
> {
> 	return vfs_parse_fs_str_len(fc, key, value, value ? strlen(value) : 0);
> }
> 
> Is any arch other than i386 limited to fewer than four register arguments?

amd64, for one, but what does that have to do with anything?  If we are parsing
mount parameters at point where one or two words on stack are critical for
stack overflow, we are fucked anyway.

It's just that qstr is the usual type for string-with-length...