• C
    NFS: Avoid PUTROOTFH when managing leases · 83ca7f5a
    Chuck Lever 提交于
    Currently, the compound operation the Linux NFS client sends to the
    server to confirm a client ID looks like this:
    
    	{ SETCLIENTID_CONFIRM; PUTROOTFH; GETATTR(lease_time) }
    
    Once the lease is confirmed, it makes sense to know how long before
    the client will have to renew it.  And, performing these operations
    in the same compound saves a round trip.
    
    Unfortunately, this arrangement assumes that the security flavor
    used for establishing a client ID can also be used to access the
    server's pseudo-fs.
    
    If the server requires a different security flavor to access its
    pseudo-fs than it allowed for the client's SETCLIENTID operation,
    the PUTROOTFH in this compound fails with NFS4ERR_WRONGSEC.  Even
    though the SETCLIENTID_CONFIRM succeeded, our client's trunking
    detection logic interprets the failure of the compound as a failure
    by the server to confirm the client ID.
    
    As part of server trunking detection, the client then begins another
    SETCLIENTID pass with the same nfs4_client_id.  This fails with
    NFS4ERR_CLID_INUSE because the first SETCLIENTID/SETCLIENTID_CONFIRM
    already succeeded in confirming that client ID -- it was the
    PUTROOTFH operation that caused the SETCLIENTID_CONFIRM compound to
    fail.
    
    To address this issue, separate the "establish client ID" step from
    the "accessing the server's pseudo-fs root" step.  The first access
    of the server's pseudo-fs may require retrying the PUTROOTFH
    operation with different security flavors.  This access is done in
    nfs4_proc_get_rootfh().
    
    That leaves the matter of how to retrieve the server's lease time.
    nfs4_proc_fsinfo() already retrieves the lease time value, though
    none of its callers do anything with the retrieved value (nor do
    they mark the lease as "renewed").
    
    Note that NFSv4.1 state recovery invokes nfs4_proc_get_lease_time()
    using the lease management security flavor.  This may cause some
    heartburn if that security flavor isn't the same as the security
    flavor the server requires for accessing the pseudo-fs.
    Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
    Cc: Bryan Schumaker <bjschuma@netapp.com>
    Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
    83ca7f5a
nfs4xdr.c 189.1 KB