>> NACK. We don't ever want to run synchronous RPC calls from inside an >> rpciod context. There be deadlocks... ahhh yes, I missed the fact that nfs4_free_revoked_stateid() is safe in calling nfs4_test_and_free_stateid() because it is bypassing the TEST_STATEID by setting stateid->type = NFS4_REVOKED_STATEID_TYPE. > So, my question is why would we need to change nfs4_delegreturn_done at > all? It should already be sending a FREE_STATEID when the server > returns NFS4ERR_EXPIRED or NFS4ERR_DELEG_REVOKED thanks to the call to > nfs4_free_revoked_stateid(). > > If the server is returning anything other than those 2 errors for a > stateid that is pending a FREE_STATEID from the client, then that > server is broken. My intent (with the BAD/STALE_STATEID part at least) was to fail safe even in the presence of a broken server. As to the other bit, the hypothesis is a bad response to PUTFH. (I cannot prove that I or others have seen this, BTW) What is the appropriate client/server response(s) if the delegation is revoked and the PUTFH fails? The server should send the error on the PUTFH before evaluating the DELEGRETURN, correct? Thanks, Andy -- Andrew W. Elble Infrastructure Engineer Information and Technology Services Rochester Institute of Technology tel: (585)-475-2411 | aweits@xxxxxxx PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912
