Message ID | 165544254397.247784.17488951418549565189.stgit@donald.themaw.net (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | vfs: fix a couple of mount table handling problems | expand |
On Fri, Jun 17, 2022 at 01:09:03PM +0800, Ian Kent wrote: > Parsing an fs string that has zero length should result in the parameter > being set to NULL so that downstream processing handles it correctly. > For example, the proc mount table processing should print "(none)" in > this case to preserve mount record field count, but if the value points > to the NULL string this doesn't happen. > > Signed-off-by: Ian Kent <raven@themaw.net> > --- Makes sense. Though I feel this is might be one of those instances where we detect that some code isn't prepared for param.string to be NULL at some point... Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
diff --git a/fs/fs_context.c b/fs/fs_context.c index 24ce12f0db32..4c735d0ce3cb 100644 --- a/fs/fs_context.c +++ b/fs/fs_context.c @@ -175,9 +175,13 @@ int vfs_parse_fs_string(struct fs_context *fc, const char *key, }; if (value) { - param.string = kmemdup_nul(value, v_size, GFP_KERNEL); - if (!param.string) - return -ENOMEM; + if (!v_size) + param.string = NULL; + else { + param.string = kmemdup_nul(value, v_size, GFP_KERNEL); + if (!param.string) + return -ENOMEM; + } param.type = fs_value_is_string; }
Parsing an fs string that has zero length should result in the parameter being set to NULL so that downstream processing handles it correctly. For example, the proc mount table processing should print "(none)" in this case to preserve mount record field count, but if the value points to the NULL string this doesn't happen. Signed-off-by: Ian Kent <raven@themaw.net> --- fs/fs_context.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)