Re: [PATCH] nfs41: Initialize slot->seq_nr at nfs4_init_slot_table()

[Vitaliy Gusev <gusev.vitaliy@nexenta.com>]

On 02/15/2012 02:46 AM, Myklebust, Trond wrote:
> Hi Vitaliy.
>
> What's wrong with sa_sequenceid == 0? I can't see anything in the spec
> that states that the sequenceid is supposed to be initialised to 1.

That is good question.

  In 2.10.6.1.  "Slot Identifiers and Reply Cache":


    A slot contains a sequence ID and the cached reply corresponding to
    the request sent with that sequence ID.  The sequence ID is a 32-bit
    unsigned value, and is therefore in the range 0..0xFFFFFFFF (2^32 -
    1).  The first time a slot is used, the requester MUST specify a
    sequence ID of one (Section 18.36).


  In 18.36.4.4 "Session creation":

        For each slot in the reply cache, the
        server sets the sequence ID to zero, and records an entry
                                    ^^^^^^^^^

       containing a COMPOUND reply with zero operations and the error
        NFS4ERR_SEQ_MISORDERED.  This way, if the first SEQUENCE request
        sent has a sequence ID equal to zero, the server can simply
                                  ^^^^^^^^^^^^

        return what is in the reply cache: NFS4ERR_SEQ_MISORDERED.  The
        client initializes its reply cache for receiving callbacks in the
        same way, and similarly, the first CB_SEQUENCE operation on a
        slot after session creation MUST have a sequence ID of one.


So sending "zero" sa_sequenceid is allowed.
But if Linux NFS server receives first OP_SEQUENCE with "sa_sequenceid 
== 0", it replies "NFS4ERR_RETRY_UNCACHED_REP"  (for OP_PUTROOTFH) - but 
expected SEQ_MISORDERED for OP_SEQUENCE.  Illumos NFSv4.1 implementation 
returns allowed SEQ_MISORDERED.

So why just do not fix receiving error and correct sending sa_sequenceid 
to 1?