Re: [PATCH v3 0/5] add CB_NOTIFY_LOCK support to knfsd

[Jeff Layton <jlayton@redhat.com>]

On Fri, 2016-09-23 at 17:05 -0400, J. Bruce Fields wrote:
> On Fri, Sep 16, 2016 at 04:28:22PM -0400, Jeff Layton wrote:
> > 
> > v3:
> > - add NFS4_OPEN_RESULT_MAY_NOTIFY_LOCK in a separate patch
> > 
> > v2:
> > - small bugfixes
> > 
> > Very minor update to the patchset I sent a week or so ago. The only real
> > difference from the last is to move the addition of
> > NFS4_OPEN_RESULT_MAY_NOTIFY_LOCK to a separate patch.
> > 
> > The basic idea is to just add support for CB_NOTIFY_LOCK callbacks,
> > which just tell the client that it may want to retry a lock again
> > once it becomes available.
> > 
> > Tested in conjunction with the corresponding client-side patch
> > series.
> 
> What sort of test were you doing?
> 

I did several: cthon (of course), the lockperf suite (which still takes
quite a while to run). Mostly I just verified that I got callbacks when
expected and that the client acted on them using wireshark. Some testing
under more load would be great.

> Have you checked with wireshark's CB_NOTIFY_LOCK support is complete?
> 

Just recently fixed:

https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=1948f7bd7553f215dc2519a35dcd62e29e35a614


> > 
> > 
> > Jeff Layton (5):
> >   nfsd: plumb in a CB_NOTIFY_LOCK operation
> >   nfsd: have nfsd4_lock use blocking locks for v4.1+ locks
> >   nfsd: add a LRU list for blocked locks
> >   nfs: add a new NFS4_OPEN_RESULT_MAY_NOTIFY_LOCK constant
> >   nfsd: set the MAY_NOTIFY_LOCK flag in OPEN replies
> > 
> >  fs/nfsd/netns.h           |   1 +
> >  fs/nfsd/nfs4callback.c    |  57 ++++++++++++
> >  fs/nfsd/nfs4state.c       | 232 ++++++++++++++++++++++++++++++++++++++++++----
> >  fs/nfsd/state.h           |  21 ++++-
> >  fs/nfsd/xdr4cb.h          |   9 ++
> >  include/uapi/linux/nfs4.h |   5 +-
> >  6 files changed, 301 insertions(+), 24 deletions(-)
> > 
> > -- 
> > 2.7.4

-- 
Jeff Layton <jlayton@redhat.com>