On Tue, 25 Mar 2025 at 17:19, <trondmy@xxxxxxxxxx> wrote: > > From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > > With the recent patch series that caused containerised mounts which > return ENETUNREACH or ENETDOWN errors to report fatal errors, we also > want to ensure that the state manager thread also triggers fatal errors > in the processes or threads that are waiting for recovery to complete. > > --- > v2: > - Return EIO instead of ENETUNREACH in nfs4_wait_clnt_recover() > > Trond Myklebust (4): > SUNRPC: rpcbind should never reset the port to the value '0' > SUNRPC: rpc_clnt_set_transport() must not change the autobind setting > NFSv4: clp->cl_cons_state < 0 signifies an invalid nfs_client > NFSv4: Treat ENETUNREACH errors as fatal for state recovery > > fs/nfs/nfs4state.c | 14 +++++++++++--- > net/sunrpc/clnt.c | 3 --- > net/sunrpc/rpcb_clnt.c | 5 +++-- > 3 files changed, 14 insertions(+), 8 deletions(-) 1. Can this "ENETUNREACH or ENETDOWN are fatal" feature be turned off? 2. We have concerns about this feature - what will happen if a switch or router gets rebooted? What will happen if you unplug your laptop? What will happen if you enable/disable your VPN software on a machine or container? What will happen if you switch WIFIs on your laptop? All these scenarios will trigger a temporary ENETUNREACH or ENETDOWN, and should NOT be fatal for mounts or containers. Lionel
