From: Mike Snitzer <snitzer@kernel.org>
To: linux-nfs@vger.kernel.org
Cc: Anna Schumaker <anna@kernel.org>,
Trond Myklebust <trondmy@hammerspace.com>,
Chuck Lever <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>
Subject: [PATCH v2] nfsd: disallow file locking and delegations for NFSv4 proxy
Date: Wed, 23 Oct 2024 11:29:40 -0400 [thread overview]
Message-ID: <20241023152940.63479-1-snitzer@kernel.org> (raw)
In-Reply-To: <20241023145436.63240-1-snitzer@kernel.org>
We do not and cannot support NFS proxy server file locking over
NFSv4.x for the same reason we don't do it for NFSv3: NFS proxy server
reboot cannot allow clients to recover locks because the source NFS
server has not rebooted, and so it is not in grace. Since the source
NFS server is not in grace, it cannot offer any guarantees that the
file won't have been changed between the locks getting lost and any
attempt to recover/reclaim them. The same applies to delegations and
any associated locks, so disallow them too.
Add EXPORT_OP_NOLOCKSUPPORT and exportfs_lock_op_is_unsupported(), set
EXPORT_OP_NOLOCKSUPPORT in nfs_export_ops and check for it in
nfsd4_lock(), nfsd4_locku() and nfs4_set_delegation().
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
---
Documentation/filesystems/nfs/reexport.rst | 11 ++++++++---
fs/nfs/export.c | 3 ++-
fs/nfsd/nfs4state.c | 20 ++++++++++++++++++++
include/linux/exportfs.h | 14 ++++++++++++++
4 files changed, 44 insertions(+), 4 deletions(-)
v2: enhance "Reboot recovery" section of Documentation/filesystems/nfs/reexport.rst
diff --git a/Documentation/filesystems/nfs/reexport.rst b/Documentation/filesystems/nfs/reexport.rst
index ff9ae4a46530..fdcbb3891097 100644
--- a/Documentation/filesystems/nfs/reexport.rst
+++ b/Documentation/filesystems/nfs/reexport.rst
@@ -26,9 +26,14 @@ Reboot recovery
---------------
The NFS protocol's normal reboot recovery mechanisms don't work for the
-case when the reexport server reboots. Clients will lose any locks
-they held before the reboot, and further IO will result in errors.
-Closing and reopening files should clear the errors.
+case when the reexport server reboots because the source server has not
+rebooted, and so it is not in grace. Since the source server is not in
+grace, it cannot offer any guarantees that the file won't have been
+changed between the locks getting lost and any attempt to recover them.
+The same applies to delegations and any associated locks. Clients will
+lose any locks and delegations they held before the reexport server
+reboot, and further IO will result in errors. Closing and reopening
+files should clear the errors.
Filehandle limits
-----------------
diff --git a/fs/nfs/export.c b/fs/nfs/export.c
index be686b8e0c54..2f001a0273bc 100644
--- a/fs/nfs/export.c
+++ b/fs/nfs/export.c
@@ -154,5 +154,6 @@ const struct export_operations nfs_export_ops = {
EXPORT_OP_CLOSE_BEFORE_UNLINK |
EXPORT_OP_REMOTE_FS |
EXPORT_OP_NOATOMIC_ATTR |
- EXPORT_OP_FLUSH_ON_CLOSE,
+ EXPORT_OP_FLUSH_ON_CLOSE |
+ EXPORT_OP_NOLOCKSUPPORT,
};
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index ac1859c7cc9d..63297ea82e4e 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -5813,6 +5813,15 @@ nfs4_set_delegation(struct nfsd4_open *open, struct nfs4_ol_stateid *stp,
if (!nf)
return ERR_PTR(-EAGAIN);
+ /*
+ * File delegations and associated locks cannot be recovered if
+ * export is from NFS proxy server.
+ */
+ if (exportfs_lock_op_is_unsupported(nf->nf_file->f_path.mnt->mnt_sb->s_export_op)) {
+ nfsd_file_put(nf);
+ return ERR_PTR(-EOPNOTSUPP);
+ }
+
spin_lock(&state_lock);
spin_lock(&fp->fi_lock);
if (nfs4_delegation_exists(clp, fp))
@@ -7917,6 +7926,11 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
}
sb = cstate->current_fh.fh_dentry->d_sb;
+ if (exportfs_lock_op_is_unsupported(sb->s_export_op)) {
+ status = nfserr_notsupp;
+ goto out;
+ }
+
if (lock->lk_is_new) {
if (nfsd4_has_session(cstate))
/* See rfc 5661 18.10.3: given clientid is ignored: */
@@ -8266,6 +8280,12 @@ nfsd4_locku(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
status = nfserr_lock_range;
goto put_stateid;
}
+
+ if (exportfs_lock_op_is_unsupported(nf->nf_file->f_path.mnt->mnt_sb->s_export_op)) {
+ status = nfserr_notsupp;
+ goto put_file;
+ }
+
file_lock = locks_alloc_lock();
if (!file_lock) {
dprintk("NFSD: %s: unable to allocate lock!\n", __func__);
diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
index 893a1d21dc1c..106fd590d323 100644
--- a/include/linux/exportfs.h
+++ b/include/linux/exportfs.h
@@ -247,6 +247,7 @@ struct export_operations {
*/
#define EXPORT_OP_FLUSH_ON_CLOSE (0x20) /* fs flushes file data on close */
#define EXPORT_OP_ASYNC_LOCK (0x40) /* fs can do async lock request */
+#define EXPORT_OP_NOLOCKSUPPORT (0x80) /* no file locking support */
unsigned long flags;
};
@@ -263,6 +264,19 @@ exportfs_lock_op_is_async(const struct export_operations *export_ops)
return export_ops->flags & EXPORT_OP_ASYNC_LOCK;
}
+/**
+ * exportfs_lock_op_is_unsupported() - export does not support file locking
+ * @export_ops: the nfs export operations to check
+ *
+ * Returns true if the nfs export_operations structure has
+ * EXPORT_OP_NOLOCKSUPPORT in their flags set
+ */
+static inline bool
+exportfs_lock_op_is_unsupported(const struct export_operations *export_ops)
+{
+ return export_ops->flags & EXPORT_OP_NOLOCKSUPPORT;
+}
+
extern int exportfs_encode_inode_fh(struct inode *inode, struct fid *fid,
int *max_len, struct inode *parent,
int flags);
--
2.44.0
next prev parent reply other threads:[~2024-10-23 15:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 14:54 [PATCH] nfsd: disallow file locking and delegations for NFSv4 proxy Mike Snitzer
2024-10-23 15:03 ` Chuck Lever
2024-10-23 15:29 ` Mike Snitzer [this message]
2024-10-23 15:58 ` [PATCH v3] nfsd: disallow file locking and delegations for NFSv4 reexport Mike Snitzer
2024-10-29 13:57 ` Martin Wege
2024-10-29 14:11 ` Chuck Lever III
2024-10-29 15:54 ` Brian Cowan
2024-10-29 16:03 ` Chuck Lever III
2024-10-30 14:55 ` Cedric Blancher
2024-10-30 16:15 ` Chuck Lever III
2024-10-30 16:37 ` Cedric Blancher
2024-10-30 16:59 ` Chuck Lever III
2024-10-30 22:48 ` Rick Macklem
2024-10-31 11:43 ` Jeff Layton
2024-10-31 14:48 ` Rick Macklem
2024-10-31 15:01 ` Chuck Lever III
2024-10-31 16:02 ` Rick Macklem
2024-10-31 15:14 ` Chuck Lever
2024-11-18 18:57 ` Chuck Lever
2024-11-19 0:37 ` Daire Byrne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241023152940.63479-1-snitzer@kernel.org \
--to=snitzer@kernel.org \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox