* [PATCH 0/2] Two more places that need to handle ENETDOWN/ENETUNREACH @ 2025-04-06 9:11 trondmy 2025-04-06 9:11 ` [PATCH 1/2] NFSv4: Handle fatal ENETDOWN and ENETUNREACH errors trondmy 2025-04-06 9:11 ` [PATCH 2/2] NFSv4/pnfs: Layoutreturn on close must handle fatal networking errors trondmy 0 siblings, 2 replies; 7+ messages in thread From: trondmy @ 2025-04-06 9:11 UTC (permalink / raw) To: Omar Sandoval; +Cc: Jeff Layton, Chris Mason, linux-nfs From: Trond Myklebust <trond.myklebust@hammerspace.com> Omar Sandoval reports seeing layouts that are leaked when a container is shut down uncleanly. Trond Myklebust (2): NFSv4: Handle fatal ENETDOWN and ENETUNREACH errors NFSv4/pnfs: Layoutreturn on close must handle fatal networking errors fs/nfs/nfs4proc.c | 9 +++++++++ fs/nfs/pnfs.c | 10 +++++++++- 2 files changed, 18 insertions(+), 1 deletion(-) -- 2.49.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/2] NFSv4: Handle fatal ENETDOWN and ENETUNREACH errors 2025-04-06 9:11 [PATCH 0/2] Two more places that need to handle ENETDOWN/ENETUNREACH trondmy @ 2025-04-06 9:11 ` trondmy 2025-04-06 13:08 ` Jeff Layton 2025-04-06 9:11 ` [PATCH 2/2] NFSv4/pnfs: Layoutreturn on close must handle fatal networking errors trondmy 1 sibling, 1 reply; 7+ messages in thread From: trondmy @ 2025-04-06 9:11 UTC (permalink / raw) To: Omar Sandoval; +Cc: Jeff Layton, Chris Mason, linux-nfs From: Trond Myklebust <trond.myklebust@hammerspace.com> Ensure that the NFSv4 error handling code recognises the RPC_TASK_NETUNREACH_FATAL flag, and handles the ENETDOWN and ENETUNREACH errors accordingly. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> --- fs/nfs/nfs4proc.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index da97f87ecaa9..f862c862b3a3 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -671,6 +671,15 @@ nfs4_async_handle_exception(struct rpc_task *task, struct nfs_server *server, struct nfs_client *clp = server->nfs_client; int ret; + if ((task->tk_rpc_status == -ENETDOWN || + task->tk_rpc_status == -ENETUNREACH) && + task->tk_flags & RPC_TASK_NETUNREACH_FATAL) { + exception->retry = 0; + exception->recovering = 0; + exception->retry = 0; + return -EIO; + } + ret = nfs4_do_handle_exception(server, errorcode, exception); if (exception->delay) { int ret2 = nfs4_exception_should_retrans(server, exception); -- 2.49.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] NFSv4: Handle fatal ENETDOWN and ENETUNREACH errors 2025-04-06 9:11 ` [PATCH 1/2] NFSv4: Handle fatal ENETDOWN and ENETUNREACH errors trondmy @ 2025-04-06 13:08 ` Jeff Layton 2025-04-06 15:28 ` Trond Myklebust 0 siblings, 1 reply; 7+ messages in thread From: Jeff Layton @ 2025-04-06 13:08 UTC (permalink / raw) To: trondmy, Omar Sandoval; +Cc: Chris Mason, linux-nfs On Sun, 2025-04-06 at 11:11 +0200, trondmy@kernel.org wrote: > From: Trond Myklebust <trond.myklebust@hammerspace.com> > > Ensure that the NFSv4 error handling code recognises the > RPC_TASK_NETUNREACH_FATAL flag, and handles the ENETDOWN and ENETUNREACH > errors accordingly. > > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> > --- > fs/nfs/nfs4proc.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c > index da97f87ecaa9..f862c862b3a3 100644 > --- a/fs/nfs/nfs4proc.c > +++ b/fs/nfs/nfs4proc.c > @@ -671,6 +671,15 @@ nfs4_async_handle_exception(struct rpc_task *task, struct nfs_server *server, > struct nfs_client *clp = server->nfs_client; > int ret; > > + if ((task->tk_rpc_status == -ENETDOWN || > + task->tk_rpc_status == -ENETUNREACH) && > + task->tk_flags & RPC_TASK_NETUNREACH_FATAL) { > + exception->retry = 0; > + exception->recovering = 0; > + exception->retry = 0; Why set exception->retry twice? > + return -EIO; > + } > + > ret = nfs4_do_handle_exception(server, errorcode, exception); > if (exception->delay) { > int ret2 = nfs4_exception_should_retrans(server, exception); Other than that, this looks sane. Reviewed-by: Jeff Layton <jlayton@kernel.org> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] NFSv4: Handle fatal ENETDOWN and ENETUNREACH errors 2025-04-06 13:08 ` Jeff Layton @ 2025-04-06 15:28 ` Trond Myklebust 0 siblings, 0 replies; 7+ messages in thread From: Trond Myklebust @ 2025-04-06 15:28 UTC (permalink / raw) To: Jeff Layton, Omar Sandoval; +Cc: Chris Mason, linux-nfs On Sun, 2025-04-06 at 09:08 -0400, Jeff Layton wrote: > On Sun, 2025-04-06 at 11:11 +0200, trondmy@kernel.org wrote: > > From: Trond Myklebust <trond.myklebust@hammerspace.com> > > > > Ensure that the NFSv4 error handling code recognises the > > RPC_TASK_NETUNREACH_FATAL flag, and handles the ENETDOWN and > > ENETUNREACH > > errors accordingly. > > > > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> > > --- > > fs/nfs/nfs4proc.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c > > index da97f87ecaa9..f862c862b3a3 100644 > > --- a/fs/nfs/nfs4proc.c > > +++ b/fs/nfs/nfs4proc.c > > @@ -671,6 +671,15 @@ nfs4_async_handle_exception(struct rpc_task > > *task, struct nfs_server *server, > > struct nfs_client *clp = server->nfs_client; > > int ret; > > > > + if ((task->tk_rpc_status == -ENETDOWN || > > + task->tk_rpc_status == -ENETUNREACH) && > > + task->tk_flags & RPC_TASK_NETUNREACH_FATAL) { > > + exception->retry = 0; > > + exception->recovering = 0; > > + exception->retry = 0; > > Why set exception->retry twice? Oops. That last one is supposed to be exception->delay = 0 Thanks for noticing! > > > + return -EIO; > > + } > > + > > ret = nfs4_do_handle_exception(server, errorcode, > > exception); > > if (exception->delay) { > > int ret2 = nfs4_exception_should_retrans(server, > > exception); > > Other than that, this looks sane. > > Reviewed-by: Jeff Layton <jlayton@kernel.org> ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 2/2] NFSv4/pnfs: Layoutreturn on close must handle fatal networking errors 2025-04-06 9:11 [PATCH 0/2] Two more places that need to handle ENETDOWN/ENETUNREACH trondmy 2025-04-06 9:11 ` [PATCH 1/2] NFSv4: Handle fatal ENETDOWN and ENETUNREACH errors trondmy @ 2025-04-06 9:11 ` trondmy 2025-04-06 13:16 ` Jeff Layton 1 sibling, 1 reply; 7+ messages in thread From: trondmy @ 2025-04-06 9:11 UTC (permalink / raw) To: Omar Sandoval; +Cc: Jeff Layton, Chris Mason, linux-nfs From: Trond Myklebust <trond.myklebust@hammerspace.com> If we have a fatal ENETDOWN or ENETUNREACH error, then the layoutreturn on close code should also handle that as fatal, and free the layouts. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> --- fs/nfs/pnfs.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c index 5f582713bf05..3554046b5bfc 100644 --- a/fs/nfs/pnfs.c +++ b/fs/nfs/pnfs.c @@ -1659,8 +1659,16 @@ int pnfs_roc_done(struct rpc_task *task, struct nfs4_layoutreturn_args **argpp, break; case -NFS4ERR_NOMATCHING_LAYOUT: /* Was there an RPC level error? If not, retry */ - if (task->tk_rpc_status == 0) + if (task->tk_rpc_status == 0) { + if ((task->tk_rpc_status == -ENETDOWN || + task->tk_rpc_status == -ENETUNREACH) && + task->tk_flags & RPC_TASK_NETUNREACH_FATAL) { + *ret = 0; + (*respp)->lrs_present = 0; + retval = -EIO; + } break; + } /* If the call was not sent, let caller handle it */ if (!RPC_WAS_SENT(task)) return 0; -- 2.49.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] NFSv4/pnfs: Layoutreturn on close must handle fatal networking errors 2025-04-06 9:11 ` [PATCH 2/2] NFSv4/pnfs: Layoutreturn on close must handle fatal networking errors trondmy @ 2025-04-06 13:16 ` Jeff Layton 2025-04-06 15:29 ` Trond Myklebust 0 siblings, 1 reply; 7+ messages in thread From: Jeff Layton @ 2025-04-06 13:16 UTC (permalink / raw) To: trondmy, Omar Sandoval; +Cc: Chris Mason, linux-nfs On Sun, 2025-04-06 at 11:11 +0200, trondmy@kernel.org wrote: > From: Trond Myklebust <trond.myklebust@hammerspace.com> > > If we have a fatal ENETDOWN or ENETUNREACH error, then the layoutreturn > on close code should also handle that as fatal, and free the layouts. > > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> > --- > fs/nfs/pnfs.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c > index 5f582713bf05..3554046b5bfc 100644 > --- a/fs/nfs/pnfs.c > +++ b/fs/nfs/pnfs.c > @@ -1659,8 +1659,16 @@ int pnfs_roc_done(struct rpc_task *task, struct nfs4_layoutreturn_args **argpp, > break; > case -NFS4ERR_NOMATCHING_LAYOUT: > /* Was there an RPC level error? If not, retry */ > - if (task->tk_rpc_status == 0) > + if (task->tk_rpc_status == 0) { > + if ((task->tk_rpc_status == -ENETDOWN || > + task->tk_rpc_status == -ENETUNREACH) && > + task->tk_flags & RPC_TASK_NETUNREACH_FATAL) { You already checked that task->tk_rpc_status is 0, so the inside if statement will never be true. I think you probably want to get rid if the outside if (task->tk_rpc_status == 0) condition? > + *ret = 0; > + (*respp)->lrs_present = 0; > + retval = -EIO; > + } > break; > + } > /* If the call was not sent, let caller handle it */ > if (!RPC_WAS_SENT(task)) > return 0; -- Jeff Layton <jlayton@kernel.org> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/2] NFSv4/pnfs: Layoutreturn on close must handle fatal networking errors 2025-04-06 13:16 ` Jeff Layton @ 2025-04-06 15:29 ` Trond Myklebust 0 siblings, 0 replies; 7+ messages in thread From: Trond Myklebust @ 2025-04-06 15:29 UTC (permalink / raw) To: Jeff Layton, Omar Sandoval; +Cc: Chris Mason, linux-nfs On Sun, 2025-04-06 at 09:16 -0400, Jeff Layton wrote: > On Sun, 2025-04-06 at 11:11 +0200, trondmy@kernel.org wrote: > > From: Trond Myklebust <trond.myklebust@hammerspace.com> > > > > If we have a fatal ENETDOWN or ENETUNREACH error, then the > > layoutreturn > > on close code should also handle that as fatal, and free the > > layouts. > > > > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> > > --- > > fs/nfs/pnfs.c | 10 +++++++++- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c > > index 5f582713bf05..3554046b5bfc 100644 > > --- a/fs/nfs/pnfs.c > > +++ b/fs/nfs/pnfs.c > > @@ -1659,8 +1659,16 @@ int pnfs_roc_done(struct rpc_task *task, > > struct nfs4_layoutreturn_args **argpp, > > break; > > case -NFS4ERR_NOMATCHING_LAYOUT: > > /* Was there an RPC level error? If not, retry */ > > - if (task->tk_rpc_status == 0) > > + if (task->tk_rpc_status == 0) { > > + if ((task->tk_rpc_status == -ENETDOWN || > > + task->tk_rpc_status == -ENETUNREACH) > > && > > + task->tk_flags & > > RPC_TASK_NETUNREACH_FATAL) { > > You already checked that task->tk_rpc_status is 0, so the inside if > statement will never be true. I think you probably want to get rid if > the outside > > if (task->tk_rpc_status == 0) > > condition? Sorry... Jet lagged in Switzerland. Let me move that out of the == 0 and before the !SENT... > > > + *ret = 0; > > + (*respp)->lrs_present = 0; > > + retval = -EIO; > > + } > > break; > > + } > > /* If the call was not sent, let caller handle it > > */ > > if (!RPC_WAS_SENT(task)) > > return 0; > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-04-06 15:29 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-04-06 9:11 [PATCH 0/2] Two more places that need to handle ENETDOWN/ENETUNREACH trondmy 2025-04-06 9:11 ` [PATCH 1/2] NFSv4: Handle fatal ENETDOWN and ENETUNREACH errors trondmy 2025-04-06 13:08 ` Jeff Layton 2025-04-06 15:28 ` Trond Myklebust 2025-04-06 9:11 ` [PATCH 2/2] NFSv4/pnfs: Layoutreturn on close must handle fatal networking errors trondmy 2025-04-06 13:16 ` Jeff Layton 2025-04-06 15:29 ` Trond Myklebust
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox