• NeilBrown's avatar
    [PATCH] nfsd4: fix open_reclaim seqid · bd9aac52
    NeilBrown authored
    The sequence number we store in the sequence id is the last one we received
    from the client.  So on the next operation we'll check that the client gives
    us the next higher number.
    
    We increment sequence id's at the last moment, in encode, so that we're sure
    of knowing the right error return.  (The decision to increment the sequence id
    depends on the exact error returned.)
    
    However on the *first* use of a sequence number, if we set the sequence number
    to the one received from the client and then let the increment happen on
    encode, we'll be left with a sequence number one to high.
    
    For that reason, ENCODE_SEQID_OP_TAIL only increments the sequence id on
    *confirmed* stateowners.
    
    This creates a problem for open reclaims, which are confirmed on first use.
    Therefore the open reclaim code, as a special exception, *decrements* the
    sequence id, cancelling out the undesired increment on encode.  But this
    prevents the sequence id from ever being incremented in the case where
    multiple reclaims are sent with the same openowner.  Yuch!
    
    We could add another exception to the open reclaim code, decrementing the
    sequence id only if this is the first use of the open owner.
    
    But it's simpler by far to modify the meaning of the op_seqid field: instead
    of representing the previous value sent by the client, we take op_seqid, after
    encoding, to represent the *next* sequence id that we expect from the client.
    This eliminates the need for special-case handling of the first use of a
    stateowner.
    Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
    Signed-off-by: default avatarNeil Brown <neilb@cse.unsw.edu.au>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    bd9aac52
nfs4xdr.c 61.9 KB