On Tue, 2017-10-17 at 10:46 -0400, Benjamin Coddington wrote:
> If the client issues two simultaneous OPEN calls, and the response to
> the
> first OPEN call (sequence id 1) is delayed before updating the
> nfs4_state,
> then the client's nfs4_state can transition through a complete
> lifecycle of
> OPEN (state sequence id 2), and CLOSE (state sequence id 3). When
> the
> first OPEN is finally processed, the nfs4_state is incorrectly
> transitioned
> back to NFS_OPEN_STATE for the first OPEN (sequence id
> 1). Subsequent calls
> to LOCK or CLOSE will receive NFS4ERR_BAD_STATEID, and trigger state
> recovery.
>
> Fix this by passing back the result of need_update_open_stateid() to
> the
> open() path, with the result to try again if the OPEN's stateid
> should not
> be updated.
>
Why are we worried about the special case where the client actually
finds the closed stateid in its cache?
In the more general case of your race, the stateid might not be found
at all because the CLOSE completes and is processed on the client
before it can process the reply from the delayed OPEN. If so, we really
have no way to detect that the file has actually been closed by the
server until we see the NFS4ERR_BAD_STATEID.
Note also that section 18.2.4 says that "the server SHOULD return the
invalid special stateid (the "other" value is zero and the "seqid"
field is NFS4_UINT32_MAX, see Section 8.2.3)" which further ensures
that we should not be able to match the OPEN stateid once the CLOSE is
processed on the client.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
