Please pull nfsd changes for 4.15 from:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.15
Lots of good bugfixes, including:
- fix a number of races in the NFSv4+ state code.
- fix some shutdown crashes in multiple-network-namespace cases.
- relax our 4.1 session limits; if you've an artificially low limit
to the number of 4.1 clients that can mount simultaneously, try
upgrading.
--b.
Andrew Elble (1):
nfsd: deal with revoked delegations appropriately
Arnd Bergmann (1):
nfds: avoid gettimeofday for nfssvc_boot time
Chuck Lever (2):
svcrdma: Preserve CB send buffer across retransmits
svcrdma: Enqueue after setting XPT_CLOSE in completion handlers
Colin Ian King (1):
sunrcp: make function _svc_create_xprt static
Corentin Labbe (3):
nfs_common: fix build warning in grace.c
nfs_common: move locks_in_grace comment at the right place
nfs_common: convert int to bool
Elena Reshetova (3):
fs, nfsd: convert nfs4_stid.sc_count from atomic_t to refcount_t
fs, nfsd: convert nfs4_cntl_odstate.co_odcount from atomic_t to refcount_t
fs, nfsd: convert nfs4_file.fi_ref from atomic_t to refcount_t
J. Bruce Fields (6):
nfsd: remove unnecessary nofilehandle checks
nfsd: increase DRC cache limit
nfsd: give out fewer session slots as limit approaches
nfsd4: fix cached replies to solo SEQUENCE compounds
nfsd4: catch some false session retries
rpc: remove some BUG()s
Jérémy Lefaure (1):
nfsd: use ARRAY_SIZE
Trond Myklebust (2):
SUNRPC: Fix tracepoint storage issues with svc_recv and svc_rqst_status
SUNRPC: Improve ordering of transport processing
Vasily Averin (2):
lockd: double unregister of inetaddr notifiers
nfsd: use nfs->ns.inum as net ID
fs/lockd/svc.c | 20 ++---
fs/nfs_common/grace.c | 24 +++---
fs/nfsd/fault_inject.c | 5 +-
fs/nfsd/netns.h | 2 +-
fs/nfsd/nfs3xdr.c | 10 ++-
fs/nfsd/nfs4layouts.c | 4 +-
fs/nfsd/nfs4proc.c | 19 ++---
fs/nfsd/nfs4state.c | 127 +++++++++++++++++++++++------
fs/nfsd/nfssvc.c | 4 +-
fs/nfsd/state.h | 11 ++-
fs/nfsd/xdr4.h | 13 ++-
include/linux/fs.h | 4 +-
include/linux/sunrpc/svc.h | 1 +
include/trace/events/sunrpc.h | 17 ++--
net/sunrpc/auth_gss/svcauth_gss.c | 14 ++--
net/sunrpc/svc_xprt.c | 106 ++++++++----------------
net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 6 +-
net/sunrpc/xprtrdma/svc_rdma_transport.c | 11 ++-
18 files changed, 225 insertions(+), 173 deletions(-)
On Sat, Nov 18, 2017 at 10:40 AM, J. Bruce Fields <[email protected]> wrote:
> Please pull nfsd changes for 4.15 from:
Hmm. This had a tracepoint conflict with the nfs client pull.
The resolution seems obvious and I did it, but I'd like people to
review the end result but particularly also their workflows, because I
don't think that conflict was reported anywhere and doesn't seem to
exist in next-20171115.
It certainly wasn't mentioned to me in either pull request.
Were the nfs client changes not in next?
Tssk.
Linus
Hi Linus,
On Sat, 18 Nov 2017 11:40:44 -0800 Linus Torvalds <[email protected]> wrote:
>
> On Sat, Nov 18, 2017 at 10:40 AM, J. Bruce Fields <[email protected]> wrote:
> > Please pull nfsd changes for 4.15 from:
>
> Hmm. This had a tracepoint conflict with the nfs client pull.
>
> The resolution seems obvious and I did it, but I'd like people to
> review the end result but particularly also their workflows, because I
> don't think that conflict was reported anywhere and doesn't seem to
> exist in next-20171115.
>
> It certainly wasn't mentioned to me in either pull request.
>
> Were the nfs client changes not in next?
They were not :-(
--
Cheers,
Stephen Rothwell
> On Nov 18, 2017, at 2:40 PM, Linus Torvalds <[email protected]> wrote:
>
> On Sat, Nov 18, 2017 at 10:40 AM, J. Bruce Fields <[email protected]> wrote:
>> Please pull nfsd changes for 4.15 from:
>
> Hmm. This had a tracepoint conflict with the nfs client pull.
Guessing you mean:
commit a30ccf1a9eb8c01f37675758f6359a968193d96e
Author: Chuck Lever <[email protected]>
AuthorDate: Fri Oct 20 10:35:18 2017 -0400
Commit: Anna Schumaker <[email protected]>
CommitDate: Fri Nov 17 16:43:44 2017 -0500
SUNRPC: Fix parsing failure in trace points with XIDs
mount.nf-11159 8.... 905.248380: xprt_transmit: [FAILED TO PARSE] xid=351291440 status=0 addr=192.168.2.5 port=20049
mount.nf-11159 8.... 905.248381: rpc_task_sleep: task:6210@1 flags=0e80 state=0005 status=0 timeout=60000 queue=xprt_pending
kworker/-1591 1.... 905.248419: xprt_lookup_rqst: [FAILED TO PARSE] xid=351291440 status=0 addr=192.168.2.5 port=20049
kworker/-1591 1.... 905.248423: xprt_complete_rqst: [FAILED TO PARSE] xid=351291440 status=24 addr=192.168.2.5 port=20049
Byte swapping is not available during trace-cmd report.
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
conflicted with
commit e9d4bf219c83d09579bc62512fea2ca10f025d93
Author: Trond Myklebust <[email protected]>
AuthorDate: Tue Oct 10 17:31:42 2017 -0400
Commit: J. Bruce Fields <[email protected]>
CommitDate: Wed Oct 11 17:08:52 2017 -0400
SUNRPC: Fix tracepoint storage issues with svc_recv and svc_rqst_status
There is no guarantee that either the request or the svc_xprt exist
by the time we get round to printing the trace message.
Signed-off-by: Trond Myklebust <[email protected]>
Cc: [email protected]
Signed-off-by: J. Bruce Fields <[email protected]>
and that you adjusted a30ccf1a9eb8c01f37675758f6359a968193d96e
to eliminate the merge conflict.
At a glance I don't see a problem with the finished result.
I could have separated a30ccf1a9eb8c01f37675758f6359a968193d96e
into a server-side and client-side change.
> The resolution seems obvious and I did it, but I'd like people to
> review the end result but particularly also their workflows, because I
> don't think that conflict was reported anywhere and doesn't seem to
> exist in next-20171115.
>
> It certainly wasn't mentioned to me in either pull request.
>
> Were the nfs client changes not in next?
>
> Tssk.
>
> Linus
--
Chuck Lever
On Sun, Nov 19, 2017 at 12:03:45PM -0500, Chuck Lever wrote:
>
> > On Nov 18, 2017, at 2:40 PM, Linus Torvalds <[email protected]> wrote:
> >
> > On Sat, Nov 18, 2017 at 10:40 AM, J. Bruce Fields <[email protected]> wrote:
> >> Please pull nfsd changes for 4.15 from:
> >
> > Hmm. This had a tracepoint conflict with the nfs client pull.
>
> Guessing you mean:
>
> commit a30ccf1a9eb8c01f37675758f6359a968193d96e
> Author: Chuck Lever <[email protected]>
> AuthorDate: Fri Oct 20 10:35:18 2017 -0400
> Commit: Anna Schumaker <[email protected]>
> CommitDate: Fri Nov 17 16:43:44 2017 -0500
>
> SUNRPC: Fix parsing failure in trace points with XIDs
>
> mount.nf-11159 8.... 905.248380: xprt_transmit: [FAILED TO PARSE] xid=351291440 status=0 addr=192.168.2.5 port=20049
> mount.nf-11159 8.... 905.248381: rpc_task_sleep: task:6210@1 flags=0e80 state=0005 status=0 timeout=60000 queue=xprt_pending
> kworker/-1591 1.... 905.248419: xprt_lookup_rqst: [FAILED TO PARSE] xid=351291440 status=0 addr=192.168.2.5 port=20049
> kworker/-1591 1.... 905.248423: xprt_complete_rqst: [FAILED TO PARSE] xid=351291440 status=24 addr=192.168.2.5 port=20049
>
> Byte swapping is not available during trace-cmd report.
>
> Signed-off-by: Chuck Lever <[email protected]>
> Signed-off-by: Anna Schumaker <[email protected]>
>
> conflicted with
>
> commit e9d4bf219c83d09579bc62512fea2ca10f025d93
> Author: Trond Myklebust <[email protected]>
> AuthorDate: Tue Oct 10 17:31:42 2017 -0400
> Commit: J. Bruce Fields <[email protected]>
> CommitDate: Wed Oct 11 17:08:52 2017 -0400
>
> SUNRPC: Fix tracepoint storage issues with svc_recv and svc_rqst_status
>
> There is no guarantee that either the request or the svc_xprt exist
> by the time we get round to printing the trace message.
>
> Signed-off-by: Trond Myklebust <[email protected]>
> Cc: [email protected]
> Signed-off-by: J. Bruce Fields <[email protected]>
>
> and that you adjusted a30ccf1a9eb8c01f37675758f6359a968193d96e
> to eliminate the merge conflict.
>
> At a glance I don't see a problem with the finished result.
>
> I could have separated a30ccf1a9eb8c01f37675758f6359a968193d96e
> into a server-side and client-side change.
Thanks, Chuck!
I just noticed I made a separate mistake this time around. For some
reason my pull request only included about the first half of the commits
I had queued up in linux-next.
I have some lame excuse having to do with holiday travel.
Anyway the remainder was just another 20-some bug fixes of various
levels of importance, so I think I'll just send another request for -rc2
tomorrow....
--b.
Hi Anna,
On Thu, 30 Nov 2017 15:53:22 -0500 Anna Schumaker <[email protected]> wrote:
>
> On 11/30/2017 03:47 PM, Stephen Rothwell wrote:
> >
> > On Thu, 30 Nov 2017 15:24:59 -0500 Anna Schumaker <[email protected]> wrote:
> >>
> >> What are the steps for adding my tree to next?
> >
> > I just need a (git) url for the tree and branch (or tag) that you will
> > update when stuff is ready to be in linux-next. I will fetch that
> > branch every morning, so once set up I automatically get updates.
>
> Let's go with the "linux-next" branch at git://git.linux-nfs.org/projects/anna/linux-nfs.git
>
> >
> > Also, a list of contacts that I can report problems (conflicts, build
> > failures/warnings etc) to (probably yourself, but maybe a mailing list
> > and any others who can fix problems.
> >
>
> Let's go with me ([email protected]), Trond ([email protected]), and [email protected].
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgement of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
[email protected]