| Message ID | 1720729462-30935-1-git-send-email-prakash.sangappa@oracle.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | vfs: ensure mount source is set to "none" if empty string specified | expand |
> The issue can be easily reproduced. > #mount -t tmpfs "" /tmp/tdir > #grep "/tmp/tdir" /proc/$$/mountinfo The kernel has accepted "" before the new mount api was introduced. So the regression was showing "none" when userspace requested "" which got fixed. The patch proposed right here would reintroduce the regression: (1) 4.15 root@b1:~# cat /proc/self/mountinfo | grep mnt 386 28 0:52 / /mnt rw,relatime shared:223 - tmpfs rw (2) 5.4 root@f1:~# cat /proc/self/mountinfo | grep mnt 584 31 0:55 / /mnt rw,relatime shared:336 - tmpfs none rw (3) 6.10-rc6 root@localhost:~# cat /proc/self/mountinfo | grep mnt 62 130 0:60 / /mnt rw,relatime shared:135 - tmpfs rw,inode64
> On Jul 15, 2024, at 5:35 AM, Christian Brauner <brauner@kernel.org> wrote: > >> The issue can be easily reproduced. >> #mount -t tmpfs "" /tmp/tdir >> #grep "/tmp/tdir" /proc/$$/mountinfo > > The kernel has accepted "" before the new mount api was introduced. So > the regression was showing "none" when userspace requested "" which got > fixed. The patch proposed right here would reintroduce the regression: The commit messages do not indicate that ’none’ caused a regression and was changed back to being empty string again, unless I missed it. I was under the impression ’none’ was added to address issues with parsing mount entries in /proc/<pid>mountinfo. Below was a patch proposal describing the parsing issues with libmount and other software because the mount source is empty. Don’t think this patch was merged. https://patchwork.kernel.org/project/linux-fsdevel/patch/1524109641-45617-1-git-send-email-cofyc.jackson@gmail.com/ Due to changes in v5.4 timeframe the mount entry started showing ’none’ for source name. Our Database application ran into an issue with libmount when moving from running on v5.4* kernel to v5.15* kernel version. > > (1) 4.15 > root@b1:~# cat /proc/self/mountinfo | grep mnt > 386 28 0:52 / /mnt rw,relatime shared:223 - tmpfs rw > > (2) 5.4 > root@f1:~# cat /proc/self/mountinfo | grep mnt > 584 31 0:55 / /mnt rw,relatime shared:336 - tmpfs none rw > > (3) 6.10-rc6 > root@localhost:~# cat /proc/self/mountinfo | grep mnt > 62 130 0:60 / /mnt rw,relatime shared:135 - tmpfs rw,inode64
diff --git a/fs/namespace.c b/fs/namespace.c index 5a51315..409b48c 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -1100,7 +1100,8 @@ struct vfsmount *vfs_create_mount(struct fs_context *fc) if (!fc->root) return ERR_PTR(-EINVAL); - mnt = alloc_vfsmnt(fc->source ?: "none"); + mnt = alloc_vfsmnt(fc->source && strlen(fc->source) > 0 ? + fc->source : "none"); if (!mnt) return ERR_PTR(-ENOMEM);
Due to changes from commit 0f89589a8c6f1033cb847a606517998efb0da8ee mount source devname is no longer getting set to 'none' if an empty source string is passed. Therefore /proc/<PID>/mountinfo will have a empty string for source devname instead of 'none'. This is due to following change in this commit in vfs_parse_fs_string() - if (v_size > 0) { + if (value) { param.string = kmemdup_nul(value, v_size, GFP_KERNEL); if (!param.string) return -ENOMEM; + param.type = fs_value_is_string; } That results in fc->source, which is copied from param.string, to point to an empty string instead of it being NULL. So, alloc_vfsmnt() called from vfs_create_mount() would be passed the empty string in fc->source not 'none'. This patch fix checks if fc->source is an empty string in the call to alloc_vfsmnt() and passes 'none'. The issue can be easily reproduced. #mount -t tmpfs "" /tmp/tdir #grep "/tmp/tdir" /proc/$$/mountinfo With the fix 506 103 0:48 / /tmp/tdir rw,relatime shared:268 - tmpfs none rw,... Without the fix 506 103 0:48 / /tmp/tdir rw,relatime shared:268 - tmpfs rw,... Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com> --- fs/namespace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)