Hi, On Fri, Aug 25, 2023 at 1:21 PM Chuck Lever <chuck.le...@oracle.com> 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 <jlay...@kernel.org> > > Signed-off-by: Alexander Aring <aahri...@redhat.com> > > --- > > 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