| Message ID | 20240414170109.137696-1-martin@kaiser.cx (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v3] nfs: keep server info for remounts | expand |
On Sun, 2024-04-14 at 19:01 +0200, Martin Kaiser wrote: > With newer kernels that use fs_context for nfs mounts, remounts fail with > -EINVAL. > > $ mount -t nfs -o nolock 10.0.0.1:/tmp/test /mnt/test/ > $ mount -t nfs -o remount /mnt/test/ > mount: mounting 10.0.0.1:/tmp/test on /mnt/test failed: Invalid argument > > For remounts, the nfs server address and port are populated by > nfs_init_fs_context and later overwritten with 0x00 bytes by > nfs23_parse_monolithic. The remount then fails as the server address is > invalid. > > Fix this by not overwriting nfs server info in nfs23_parse_monolithic if > we're doing a remount. > > Fixes: f2aedb713c28 ("NFS: Add fs_context support.") > Signed-off-by: Martin Kaiser <martin@kaiser.cx> > --- > v3: > - rebased against linux-next from 12th April 2024 > > v2: > - rebased against linux-next from 26th February 2024 > > Dear all, > I'm resending this patch again. The problem that I'm trying to fix is still > present in linux-next. Thanks in advance for any reviews and comments. > > I guess that we're taking this path for remounts > > do_remount > fs_context_for_reconfigure > alloc_fs_context > init_fs_context == nfs_init_fs_context > fc->root is set for remounts > ctx->nfs_server is populated > parse_monolithic_mount_data > nfs_fs_context_parse_monolithic > nfs23_parse_monolithic > ctx->nfs_server is overwritten with data from mount request > > An alternative to checking for !is_remount_fc(fc) would be to check > if (ctx->nfs_server.addrlen == 0) > > fs/nfs/fs_context.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/fs/nfs/fs_context.c b/fs/nfs/fs_context.c > index d0a0956f8a13..cac1157be2c2 100644 > --- a/fs/nfs/fs_context.c > +++ b/fs/nfs/fs_context.c > @@ -1112,9 +1112,12 @@ static int nfs23_parse_monolithic(struct fs_context *fc, > ctx->acdirmax = data->acdirmax; > ctx->need_mount = false; > > - memcpy(sap, &data->addr, sizeof(data->addr)); > - ctx->nfs_server.addrlen = sizeof(data->addr); > - ctx->nfs_server.port = ntohs(data->addr.sin_port); > + if (!is_remount_fc(fc)) { > + memcpy(sap, &data->addr, sizeof(data->addr)); > + ctx->nfs_server.addrlen = sizeof(data->addr); > + ctx->nfs_server.port = ntohs(data->addr.sin_port); > + } > + > if (sap->ss_family != AF_INET || > !nfs_verify_server_address(sap)) > goto out_no_address; Doesn't nfs4_parse_monolithic need the same fix?
Thus wrote Jeff Layton (jlayton@kernel.org): > On Sun, 2024-04-14 at 19:01 +0200, Martin Kaiser wrote: > > With newer kernels that use fs_context for nfs mounts, remounts fail with > > -EINVAL. > > $ mount -t nfs -o nolock 10.0.0.1:/tmp/test /mnt/test/ > > $ mount -t nfs -o remount /mnt/test/ > > mount: mounting 10.0.0.1:/tmp/test on /mnt/test failed: Invalid argument > > For remounts, the nfs server address and port are populated by > > nfs_init_fs_context and later overwritten with 0x00 bytes by > > nfs23_parse_monolithic. The remount then fails as the server address is > > invalid. > > Fix this by not overwriting nfs server info in nfs23_parse_monolithic if > > we're doing a remount. > > Fixes: f2aedb713c28 ("NFS: Add fs_context support.") > > Signed-off-by: Martin Kaiser <martin@kaiser.cx> > > --- > > v3: > > - rebased against linux-next from 12th April 2024 > > v2: > > - rebased against linux-next from 26th February 2024 > > Dear all, > > I'm resending this patch again. The problem that I'm trying to fix is still > > present in linux-next. Thanks in advance for any reviews and comments. > > I guess that we're taking this path for remounts > > do_remount > > fs_context_for_reconfigure > > alloc_fs_context > > init_fs_context == nfs_init_fs_context > > fc->root is set for remounts > > ctx->nfs_server is populated > > parse_monolithic_mount_data > > nfs_fs_context_parse_monolithic > > nfs23_parse_monolithic > > ctx->nfs_server is overwritten with data from mount request > > An alternative to checking for !is_remount_fc(fc) would be to check > > if (ctx->nfs_server.addrlen == 0) > > fs/nfs/fs_context.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/fs/nfs/fs_context.c b/fs/nfs/fs_context.c > > index d0a0956f8a13..cac1157be2c2 100644 > > --- a/fs/nfs/fs_context.c > > +++ b/fs/nfs/fs_context.c > > @@ -1112,9 +1112,12 @@ static int nfs23_parse_monolithic(struct fs_context *fc, > > ctx->acdirmax = data->acdirmax; > > ctx->need_mount = false; > > - memcpy(sap, &data->addr, sizeof(data->addr)); > > - ctx->nfs_server.addrlen = sizeof(data->addr); > > - ctx->nfs_server.port = ntohs(data->addr.sin_port); > > + if (!is_remount_fc(fc)) { > > + memcpy(sap, &data->addr, sizeof(data->addr)); > > + ctx->nfs_server.addrlen = sizeof(data->addr); > > + ctx->nfs_server.port = ntohs(data->addr.sin_port); > > + } > > + > > if (sap->ss_family != AF_INET || > > !nfs_verify_server_address(sap)) > > goto out_no_address; > Doesn't nfs4_parse_monolithic need the same fix? Sorry for the delayed response. It took me a moment to set up a test with nfs4 (busybox mount has no nfs4 support). The nfs4 remounts do not fail for me. The mount syscall goes into nfs4_parse_monolithic and if (data->version != 1) return generic_parse_monolithic(fc, data); branches off into generic_parse_monolithic before the server address is overwritten (this is what breaks nfs23). Best regards, Martin
diff --git a/fs/nfs/fs_context.c b/fs/nfs/fs_context.c index d0a0956f8a13..cac1157be2c2 100644 --- a/fs/nfs/fs_context.c +++ b/fs/nfs/fs_context.c @@ -1112,9 +1112,12 @@ static int nfs23_parse_monolithic(struct fs_context *fc, ctx->acdirmax = data->acdirmax; ctx->need_mount = false; - memcpy(sap, &data->addr, sizeof(data->addr)); - ctx->nfs_server.addrlen = sizeof(data->addr); - ctx->nfs_server.port = ntohs(data->addr.sin_port); + if (!is_remount_fc(fc)) { + memcpy(sap, &data->addr, sizeof(data->addr)); + ctx->nfs_server.addrlen = sizeof(data->addr); + ctx->nfs_server.port = ntohs(data->addr.sin_port); + } + if (sap->ss_family != AF_INET || !nfs_verify_server_address(sap)) goto out_no_address;
With newer kernels that use fs_context for nfs mounts, remounts fail with -EINVAL. $ mount -t nfs -o nolock 10.0.0.1:/tmp/test /mnt/test/ $ mount -t nfs -o remount /mnt/test/ mount: mounting 10.0.0.1:/tmp/test on /mnt/test failed: Invalid argument For remounts, the nfs server address and port are populated by nfs_init_fs_context and later overwritten with 0x00 bytes by nfs23_parse_monolithic. The remount then fails as the server address is invalid. Fix this by not overwriting nfs server info in nfs23_parse_monolithic if we're doing a remount. Fixes: f2aedb713c28 ("NFS: Add fs_context support.") Signed-off-by: Martin Kaiser <martin@kaiser.cx> --- v3: - rebased against linux-next from 12th April 2024 v2: - rebased against linux-next from 26th February 2024 Dear all, I'm resending this patch again. The problem that I'm trying to fix is still present in linux-next. Thanks in advance for any reviews and comments. I guess that we're taking this path for remounts do_remount fs_context_for_reconfigure alloc_fs_context init_fs_context == nfs_init_fs_context fc->root is set for remounts ctx->nfs_server is populated parse_monolithic_mount_data nfs_fs_context_parse_monolithic nfs23_parse_monolithic ctx->nfs_server is overwritten with data from mount request An alternative to checking for !is_remount_fc(fc) would be to check if (ctx->nfs_server.addrlen == 0) fs/nfs/fs_context.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)