Re: [PATCH] nfsd4: fix a deadlock on state owner replay mutex

On Thu, Jun 27, 2019 at 06:30:27PM +, 黄乐 wrote: > from: Huang Le > > In move_to_close_lru(), which only be called on path of nfsd4 CLOSE op, > the code could wait for its stid ref count drop to 2 while holding its > state owner replay mutex. However, the other stid ref holder (normally > a

Re: [PATCH 00/23 - V5] NFS: Remove generic RPC credentials.

On Tue, Dec 04, 2018 at 09:33:18PM +, Schumaker, Anna wrote: > On Tue, 2018-12-04 at 15:21 -0500, J. Bruce Fields wrote: > > On Mon, Dec 03, 2018 at 11:30:30AM +1100, NeilBrown wrote: > > > This is the same series as posted on 07 November, modified slightly > > > to match some recent code

Re: [PATCH 00/23 - V5] NFS: Remove generic RPC credentials.

On Tue, Dec 04, 2018 at 09:33:18PM +, Schumaker, Anna wrote: > On Tue, 2018-12-04 at 15:21 -0500, J. Bruce Fields wrote: > > On Mon, Dec 03, 2018 at 11:30:30AM +1100, NeilBrown wrote: > > > This is the same series as posted on 07 November, modified slightly > > > to match some recent code

Re: general protection fault in encode_rpcb_string

On Tue, Apr 17, 2018 at 09:54:36PM +, Trond Myklebust wrote: > Yes, and we can probably convert it, and the other GFP_ATOMIC > allocations in the rpcbind client to use GFP_NOFS in order to improve > reliability. Chuck, I think the GFP_ATOMIC is unnecessary here as well? --b. diff --git

Re: general protection fault in encode_rpcb_string

On Tue, Apr 17, 2018 at 09:54:36PM +, Trond Myklebust wrote: > Yes, and we can probably convert it, and the other GFP_ATOMIC > allocations in the rpcbind client to use GFP_NOFS in order to improve > reliability. Chuck, I think the GFP_ATOMIC is unnecessary here as well? --b. diff --git

Re: general protection fault in encode_rpcb_string

From: "J. Bruce Fields" Date: Tue, 8 May 2018 11:47:03 -0400 Subject: [PATCH 2/2] sunrpc: convert unnecessary GFP_ATOMIC to GFP_NOFS It's OK to sleep here, we just don't want to recurse into the filesystem as this writeout could be waiting on this. As a next step: the

Re: general protection fault in encode_rpcb_string

From: "J. Bruce Fields" Date: Tue, 8 May 2018 11:47:03 -0400 Subject: [PATCH 2/2] sunrpc: convert unnecessary GFP_ATOMIC to GFP_NOFS It's OK to sleep here, we just don't want to recurse into the filesystem as this writeout could be waiting on this. As a next step: the documentation for GFP_NOFS

[PATCH 1/2] sunrpc: handle ENOMEM in rpcb_getport_async

From: "J. Bruce Fields" If we ignore the error we'll hit a null dereference a little later. Reported-by: syzbot+4b98281f2401ab849...@syzkaller.appspotmail.com Signed-off-by: J. Bruce Fields --- net/sunrpc/rpcb_clnt.c | 8 1 file changed, 8

[PATCH 1/2] sunrpc: handle ENOMEM in rpcb_getport_async

From: "J. Bruce Fields" If we ignore the error we'll hit a null dereference a little later. Reported-by: syzbot+4b98281f2401ab849...@syzkaller.appspotmail.com Signed-off-by: J. Bruce Fields --- net/sunrpc/rpcb_clnt.c | 8 1 file changed, 8 insertions(+) diff --git

Re: [PATCH] sunrpc: Add task's xid to 'not responding' messages on call_timeout

On Sat, Feb 10, 2018 at 01:41:55AM +, Trond Myklebust wrote: > On Fri, 2018-02-09 at 23:06 -0200, Thiago Rafael Becker wrote: > > When investigating reasons for nfs failures, packet dumps arei > > eventually used. > > Finding the rpc that generated the failure is done by comparing all > > sent

Re: [PATCH] sunrpc: Add task's xid to 'not responding' messages on call_timeout

On Sat, Feb 10, 2018 at 01:41:55AM +, Trond Myklebust wrote: > On Fri, 2018-02-09 at 23:06 -0200, Thiago Rafael Becker wrote: > > When investigating reasons for nfs failures, packet dumps arei > > eventually used. > > Finding the rpc that generated the failure is done by comparing all > > sent

[GIT PULL] Please pull an nfsd bugfix for 4.13

Please pull: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.13-1 One fix for a problem introduced in the most recent merge window and found by Dave Jones and KASAN. --b. Trond Myklebust (1): nfsd: Fix a memory scribble in the callback channel fs/nfsd/nfs4callback.c | 6 +++--- 1

[GIT PULL] Please pull an nfsd bugfix for 4.13

Please pull: git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.13-1 One fix for a problem introduced in the most recent merge window and found by Dave Jones and KASAN. --b. Trond Myklebust (1): nfsd: Fix a memory scribble in the callback channel fs/nfsd/nfs4callback.c | 6 +++--- 1

Re: [HPDD-discuss] [PATCH] nfsd: add a new EXPORT_OP_NOWCC flag to struct export_operations

On Wed, Sep 16, 2015 at 01:18:29PM -0400, Jeff Layton wrote: > On Mon, 14 Sep 2015 12:10:15 -0400 > "bfie...@fieldses.org" wrote: > > > On Sat, Sep 12, 2015 at 06:24:54AM -0400, Jeff Layton wrote: > > > I don't think it matters, at least not on x86_64. bools a

Re: [HPDD-discuss] [PATCH] nfsd: add a new EXPORT_OP_NOWCC flag to struct export_operations

On Wed, Sep 16, 2015 at 01:18:29PM -0400, Jeff Layton wrote: > On Mon, 14 Sep 2015 12:10:15 -0400 > "bfie...@fieldses.org" <bfie...@fieldses.org> wrote: > > > On Sat, Sep 12, 2015 at 06:24:54AM -0400, Jeff Layton wrote: > > > I don't think it matters, at l

Re: [HPDD-discuss] [PATCH] nfsd: add a new EXPORT_OP_NOWCC flag to struct export_operations

On Sat, Sep 12, 2015 at 06:24:54AM -0400, Jeff Layton wrote: > On Sat, 12 Sep 2015 04:41:33 + > "Dilger, Andreas" wrote: > > > On 2015/09/11, 4:20 AM, "HPDD-discuss on behalf of Jeff Layton" > > > > wrote: > > > > >With NFSv3 nfsd will always attempt to send along WCC data to the > >

Re: [HPDD-discuss] [PATCH] nfsd: add a new EXPORT_OP_NOWCC flag to struct export_operations

On Sat, Sep 12, 2015 at 06:24:54AM -0400, Jeff Layton wrote: > On Sat, 12 Sep 2015 04:41:33 + > "Dilger, Andreas" wrote: > > > On 2015/09/11, 4:20 AM, "HPDD-discuss on behalf of Jeff Layton" > >

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 02:51:20PM -0400, Chuck Lever wrote: > > On Apr 25, 2013, at 2:46 PM, "bfie...@fieldses.org" > wrote: > > > On Thu, Apr 25, 2013 at 02:40:11PM -0400, Chuck Lever wrote: > >> > >> On Apr 25, 2013, at 2:19 PM, "bfie...@

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 02:40:11PM -0400, Chuck Lever wrote: > > On Apr 25, 2013, at 2:19 PM, "bfie...@fieldses.org" > wrote: > > > On Thu, Apr 25, 2013 at 02:10:36PM +, Myklebust, Trond wrote: > >> On Thu, 2013-04-25 at 09:49 -0400, bfie...@fieldses.

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 02:10:36PM +, Myklebust, Trond wrote: > On Thu, 2013-04-25 at 09:49 -0400, bfie...@fieldses.org wrote: > > On Thu, Apr 25, 2013 at 01:30:58PM +, Myklebust, Trond wrote: > > > On Thu, 2013-04-25 at 09:29 -0400, bfie...@fieldses.org wrote: > >

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 01:30:58PM +, Myklebust, Trond wrote: > On Thu, 2013-04-25 at 09:29 -0400, bfie...@fieldses.org wrote: > > > My position is that we simply have no idea what order of magnitude even > > delay should be. And that in such a situation e

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 08:19:34AM -0400, David Wysochanski wrote: > On Wed, 2013-04-24 at 22:35 +, Myklebust, Trond wrote: > > On Wed, 2013-04-24 at 16:54 -0500, Dave Chiluk wrote: > > > On 04/24/2013 04:28 PM, Myklebust, Trond wrote: > > > > On Wed, 2013-04-24 at 15:55 -0500, Dave Chiluk

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 08:19:34AM -0400, David Wysochanski wrote: On Wed, 2013-04-24 at 22:35 +, Myklebust, Trond wrote: On Wed, 2013-04-24 at 16:54 -0500, Dave Chiluk wrote: On 04/24/2013 04:28 PM, Myklebust, Trond wrote: On Wed, 2013-04-24 at 15:55 -0500, Dave Chiluk wrote:

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 01:30:58PM +, Myklebust, Trond wrote: On Thu, 2013-04-25 at 09:29 -0400, bfie...@fieldses.org wrote: My position is that we simply have no idea what order of magnitude even delay should be. And that in such a situation exponential backoff such as implemented

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 02:10:36PM +, Myklebust, Trond wrote: On Thu, 2013-04-25 at 09:49 -0400, bfie...@fieldses.org wrote: On Thu, Apr 25, 2013 at 01:30:58PM +, Myklebust, Trond wrote: On Thu, 2013-04-25 at 09:29 -0400, bfie...@fieldses.org wrote: My position is that we

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 02:40:11PM -0400, Chuck Lever wrote: On Apr 25, 2013, at 2:19 PM, bfie...@fieldses.org bfie...@fieldses.org wrote: On Thu, Apr 25, 2013 at 02:10:36PM +, Myklebust, Trond wrote: On Thu, 2013-04-25 at 09:49 -0400, bfie...@fieldses.org wrote: On Thu, Apr 25

Re: [PATCH] NFSv4: Use exponential backoff delay for NFS4_ERRDELAY

On Thu, Apr 25, 2013 at 02:51:20PM -0400, Chuck Lever wrote: On Apr 25, 2013, at 2:46 PM, bfie...@fieldses.org bfie...@fieldses.org wrote: On Thu, Apr 25, 2013 at 02:40:11PM -0400, Chuck Lever wrote: On Apr 25, 2013, at 2:19 PM, bfie...@fieldses.org bfie...@fieldses.org wrote

Re: [GIT PULL] Disintegrate UAPI for nfs

On Tue, Oct 09, 2012 at 02:13:30PM +, Myklebust, Trond wrote: > On Tue, 2012-10-09 at 14:30 +0100, David Howells wrote: > > Can you merge the following branch into the nfs tree please. > > > > This is to complete part of the Userspace API (UAPI) disintegration for > > which > > the

Re: [GIT PULL] Disintegrate UAPI for nfs

On Tue, Oct 09, 2012 at 02:13:30PM +, Myklebust, Trond wrote: On Tue, 2012-10-09 at 14:30 +0100, David Howells wrote: Can you merge the following branch into the nfs tree please. This is to complete part of the Userspace API (UAPI) disintegration for which the preparatory patches

Re: [PATCH] SUNRPC: return negative value in case rpcbind client creation error

On Mon, Jul 30, 2012 at 11:12:05PM +, Myklebust, Trond wrote: > On Fri, 2012-07-20 at 15:57 +0400, Stanislav Kinsbursky wrote: > > Without this patch kernel will panic on LockD start, because lockd_up() > > checks > > lockd_up_net() result for negative value. > > >From my pow it's better to

Re: [PATCH] SUNRPC: return negative value in case rpcbind client creation error

On Mon, Jul 30, 2012 at 11:12:05PM +, Myklebust, Trond wrote: On Fri, 2012-07-20 at 15:57 +0400, Stanislav Kinsbursky wrote: Without this patch kernel will panic on LockD start, because lockd_up() checks lockd_up_net() result for negative value. From my pow it's better to return