On 12 Nov 2016, at 13:16, Trond Myklebust wrote:
On Nov 12, 2016, at 06:08, Benjamin Coddington <bcodding@xxxxxxxxxx>
wrote:
I've been seeing the following on a modified version of generic/089
that gets the client stuck sending LOCK with NFS4ERR_OLD_STATEID.
1. Client has open stateid A, sends a CLOSE
2. Client sends OPEN with same owner
3. Client sends another OPEN with same owner
4. Client gets a reply to OPEN in 3, stateid is B.2 (stateid B
sequence 2)
5. Client does LOCK,LOCKU,FREE_STATEID from B.2
6. Client gets a reply to CLOSE in 1
7. Client gets reply to OPEN in 2, stateid is B.1
8. Client sends LOCK with B.1 - OLD_STATEID, now stuck in a loop
The CLOSE response in 6 causes us to clear NFS_OPEN_STATE, so that
the OPEN
response in 7 is able to update the open_stateid even though it has a
lower
sequence number.
Hmm… We probably should not do that if the stateid.other field of A
(i.e.
the one supplied as the argument to CLOSE) does not match the
stateid.other of B. In fact, the reply in (4), where the stateid
changes
to B, should be the thing that resets the OPEN state.
At 4, by reset the OPEN state, do you mean we should expect and wait for
a
pending close to complete, or we should start over with a brand new
state?
Maybe something else..
The reason the NFS_OPEN_STATE flag is cleared in 6 is that all the state
counts (n_rdwr, n_rdonly, n_wronly) are zero. There could be a
"pending
open" flag or counter that would help 6 not clear NFS_OPEN_STATE..
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
