Hi,
On Fri, Aug 25, 2023 at 1:21 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>
> On Wed, Aug 23, 2023 at 05:33:46PM -0400, Alexander Aring wrote:
> > This patch reverts mostly commit 40595cdc93ed ("nfs: block notification
> > on fs with its own ->lock") and introduces an EXPORT_OP_SAFE_ASYNC_LOCK
> > export flag to signal that the "own ->lock" implementation supports
> > async lock requests. The only main user is DLM that is used by GFS2 and
> > OCFS2 filesystem. Those implement their own lock() implementation and
> > return FILE_LOCK_DEFERRED as return value. Since commit 40595cdc93ed
> > ("nfs: block notification on fs with its own ->lock") the DLM
> > implementation were never updated. This patch should prepare for DLM
> > to set the EXPORT_OP_SAFE_ASYNC_LOCK export flag and update the DLM
> > plock implementation regarding to it.
> >
> > Acked-by: Jeff Layton <jlayton@xxxxxxxxxx>
> > Signed-off-by: Alexander Aring <aahringo@xxxxxxxxxx>
> > ---
> > fs/lockd/svclock.c | 5 ++---
> > fs/nfsd/nfs4state.c | 13 ++++++++++---
> > include/linux/exportfs.h | 8 ++++++++
> > 3 files changed, 20 insertions(+), 6 deletions(-)
>
> I'm starting to look at these. Just so you know, it's too late for
> inclusion in v6.6, but I think we can get these into shape for v6.7.
>
ok. I base my work on [0], is this correct?
> More below.
>
>
> > diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
> > index c43ccdf28ed9..6e3b230e8317 100644
> > --- a/fs/lockd/svclock.c
> > +++ b/fs/lockd/svclock.c
> > @@ -470,9 +470,7 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file,
> > struct nlm_host *host, struct nlm_lock *lock, int wait,
> > struct nlm_cookie *cookie, int reclaim)
> > {
> > -#if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
> > struct inode *inode = nlmsvc_file_inode(file);
> > -#endif
> > struct nlm_block *block = NULL;
> > int error;
> > int mode;
> > @@ -486,7 +484,8 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file,
> > (long long)lock->fl.fl_end,
> > wait);
> >
> > - if (nlmsvc_file_file(file)->f_op->lock) {
> > + if (!export_op_support_safe_async_lock(inode->i_sb->s_export_op,
> > + nlmsvc_file_file(file)->f_op)) {
> > async_block = wait;
> > wait = 0;
> > }
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 3aefbad4cc09..14ca06424ff1 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -7430,6 +7430,7 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> > struct nfsd4_blocked_lock *nbl = NULL;
> > struct file_lock *file_lock = NULL;
> > struct file_lock *conflock = NULL;
> > + struct super_block *sb;
> > __be32 status = 0;
> > int lkflg;
> > int err;
> > @@ -7451,6 +7452,7 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> > dprintk("NFSD: nfsd4_lock: permission denied!\n");
> > return status;
> > }
> > + sb = cstate->current_fh.fh_dentry->d_sb;
> >
> > if (lock->lk_is_new) {
> > if (nfsd4_has_session(cstate))
> > @@ -7502,7 +7504,9 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> > fp = lock_stp->st_stid.sc_file;
> > switch (lock->lk_type) {
> > case NFS4_READW_LT:
> > - if (nfsd4_has_session(cstate))
> > + if (nfsd4_has_session(cstate) ||
> > + export_op_support_safe_async_lock(sb->s_export_op,
> > + nf->nf_file->f_op))
> > fl_flags |= FL_SLEEP;
> > fallthrough;
> > case NFS4_READ_LT:
> > @@ -7514,7 +7518,9 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> > fl_type = F_RDLCK;
> > break;
> > case NFS4_WRITEW_LT:
> > - if (nfsd4_has_session(cstate))
> > + if (nfsd4_has_session(cstate) ||
> > + export_op_support_safe_async_lock(sb->s_export_op,
> > + nf->nf_file->f_op))
> > fl_flags |= FL_SLEEP;
> > fallthrough;
> > case NFS4_WRITE_LT:
> > @@ -7542,7 +7548,8 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> > * for file locks), so don't attempt blocking lock notifications
> > * on those filesystems:
> > */
> > - if (nf->nf_file->f_op->lock)
> > + if (!export_op_support_safe_async_lock(sb->s_export_op,
> > + nf->nf_file->f_op))
> > fl_flags &= ~FL_SLEEP;
> >
> > nbl = find_or_allocate_block(lock_sop, &fp->fi_fhandle, nn);
> > diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
> > index 11fbd0ee1370..10358a93cdc1 100644
> > --- a/include/linux/exportfs.h
> > +++ b/include/linux/exportfs.h
> > @@ -3,6 +3,7 @@
> > #define LINUX_EXPORTFS_H 1
> >
> > #include <linux/types.h>
> > +#include <linux/fs.h>
> >
> > struct dentry;
> > struct iattr;
> > @@ -224,9 +225,16 @@ struct export_operations {
> > atomic attribute updates
> > */
> > #define EXPORT_OP_FLUSH_ON_CLOSE (0x20) /* fs flushes file data on close */
> > +#define EXPORT_OP_SAFE_ASYNC_LOCK (0x40) /* fs can do async lock request */
>
> We haven't been good about this recently, but the addition of new
> EXPORT_OP flags need to be accompanied by updates to
> Documentation/filesystems/nfs/exporting.rst.
>
ok.
> I will see about adding documentation for other recent flags, but
> please include an update to exporting.rst with this patch.
>
ok.
> I'm not sure we need _SAFE_ in the flag name. Would
> EXPORT_OP_ASYNC_LOCK be OK with you?
>
sure, a vfs_file_lock() can return FILE_LOCK_DEFERRED as well, even
without having this export flag set. How non upstream users use it, I
have no idea as it has some races.
>
> > unsigned long flags;
> > };
> >
> > +static inline bool export_op_support_safe_async_lock(const struct export_operations *export_ops,
> > + const struct file_operations *f_op)
> > +{
> > + return (export_ops->flags & EXPORT_OP_SAFE_ASYNC_LOCK) || !f_op->lock;
> > +}
> > +
>
> I'd like some cosmetic changes to this API, since this seems to be
> the first utility function for checking EXPORT_OP flags.
>
> - The function name is unwieldy. How about exportfs_lock_op_is_async() ?
>
ok.
> - Break up the long lines. It's OK with me if the return value type
> is left on a different line than the function name and parameters.
>
ok.
> - This function is globally visible, so a kdoc comment is needed.
>
ok.
> - The f_op->lock check is common to all the call sites, but it is
> not at all related to the export AFAICT. Can it be removed from
> this inline function?
>
This flag implies it makes only sense if the filesystem has its own
lock() implementation, if it doesn't have that I guess the core fs
functions for local file locking are being used.
I guess it can be removed, but it should not be used when there is no
own ->lock() implementation, at least not now until somebody might
update the fs core functionality for local file locking to handle
blocking lock requests asynchronously.
- Alex
[0] https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git/log/?h=nfsd-next
