liyinshubyte

This is a new case which cause client hangs forever, No.33 is a GETATTR request, seqid 0x9b, slotid 4, xid 980110910 No.44 is the reply of No.33, but it's the...

@ffilz Thanks, I will continue to find the root cause.

@ffilz I found the root cause, in nfs4_op_close, ref count increase once, but decrease twice. The increasement is at [nfs_status = nfs4_Check_Stateid(&arg_CLOSE4->open_stateid,](https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/Protocols/NFS/nfs4_op_close.c#L180), the first decreasement is at [state_del_locked(state_found);](https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/Protocols/NFS/nfs4_op_close.c#L306), the second...

@ffilz Thanks, I remove `dec_state_t_ref(state)` in `state_del_locked` in patch. And I found all places, expect `nfs4_op_layoutget`, have already `dec_state_t_ref`, so we do not need to `dec_state_t_ref` in `state_del_locked`.

I use this fix in our production env, but there is memory leak of state. so there is position which forget to dec_state_t_ref, I will continue to find the root...

@ffilz Thanks, I got it. I think `state_del_locked` should only be called once during the life of state. But I found `state_del_locked` called twice, so I think this is the...

@ffilz sure, will do it.

@ffilz Hi, suppose one case, current open_state's ref count is 1, thread1: [nfs4_op_close.c:180](https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/Protocols/NFS/nfs4_op_close.c#L180) inc open_state's ref to 2 thread2: [nfs4_op_lock.c:178](https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/Protocols/NFS/nfs4_op_lock.c#L178) inc open_state's ref to 3 thread1: [nfs4_op_close.c:306](https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/Protocols/NFS/nfs4_op_close.c#L306) dec open_state's ref...

@ffilz Hi, just friendly ping.

@ffilz This is a draft patch: https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/542008. Could you help review this ? I have not test this patch, if you agree with this change, I will test it in...