On Thu, 2023-04-06 at 13:58 -0700, dai.ngo@xxxxxxxxxx wrote: > On 4/6/23 12:59 PM, Jeff Layton wrote: > > On Thu, 2023-04-06 at 19:43 +0000, Chuck Lever III wrote: > > > > On Apr 6, 2023, at 3:36 PM, Dai Ngo <dai.ngo@xxxxxxxxxx> wrote: > > > > > > > > Hi Jeff, > > > > > > > > Thank you for taking a look at the patch. > > > > > > > > On 4/6/23 11:10 AM, Jeff Layton wrote: > > > > > On Thu, 2023-04-06 at 13:33 -0400, Jeff Layton wrote: > > > > > > On Tue, 2023-03-14 at 09:19 -0700, dai.ngo@xxxxxxxxxx wrote: > > > > > > > On 3/8/23 11:03 AM, dai.ngo@xxxxxxxxxx wrote: > > > > > > > > On 3/8/23 10:50 AM, Chuck Lever III wrote: > > > > > > > > > > On Mar 8, 2023, at 1:45 PM, Dai Ngo <dai.ngo@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > Currently call_bind_status places a hard limit of 3 to the number of > > > > > > > > > > retries on EACCES error. This limit was done to accommodate the > > > > > > > > > > behavior > > > > > > > > > > of a buggy server that keeps returning garbage when the NLM daemon is > > > > > > > > > > killed on the NFS server. However this change causes problem for other > > > > > > > > > > servers that take a little longer than 9 seconds for the port mapper to > > > > > > > > > > > > > > > > > > > > > > > > > Actually, the EACCES error means that the host doesn't have the port > > > > > registered. > > > > Yes, our SQA team runs stress lock test and restart the NFS server. > > > > Sometimes the NFS server starts up and register to the port mapper in > > > > time and there is no problem but occasionally it's late coming up causing > > > > this EACCES error. > > > > > > > > > That could happen if (e.g.) the host had a NFSv3 mount up > > > > > with an NLM connection and then crashed and rebooted and didn't remount > > > > > it. > > > > can you please explain this scenario I don't quite follow it. If the v3 > > > > client crashed and did not remount the export then how can the client try > > > > to access/lock anything on the server? I must have missing something here. > > > > > > > > > > > Suppose you have a client with an admin that mounts a NFSv3 mount "by > > hand" (and doesn't set up statd to run at boot time). Client requests an > > NLM lock and then reboots. > > > > When it comes up, there's no notification to the server that the client > > rebooted. Later, the lock becomes free and the server tries to grant it > > to the client. It talks to rpcbind but lockd is never started and the > > server keeps querying the client's rpcbind forever. > > > > Maybe more likely situation: the client crashes and loses its DHCP > > address when it comes back up, and the old addr gets reassigned to > > another host that has rpcbind running but no NFS. > > > > Either way, it'd keep trying to call the client back indefinitely that > > way. > > Got it Jeff, thank you for the explanation. This is when NLM requests > are originated from the NFS server. > Mostly, yes. The old, stateless NFS v2/v3 server code didn't have much in the way of callbacks, and v4 (for the most part) doesn't rely on rpcbind. That said, there may be some RPC calls done by the v2/3 NFS client that don't have a direct connection to a client task. Consider stuff like writeback requests. Signals won't do anything there. I think keeping a hard timeout of some sort is probably prudent. > -- Jeff Layton <jlayton@xxxxxxxxxx>
