06 Jan, 2015

1 commit


26 Nov, 2014

2 commits


01 Oct, 2014

1 commit

  • The SEEK operation is used when an application makes an lseek call with
    either the SEEK_HOLE or SEEK_DATA flags set. I fall back on
    nfs_file_llseek() if the server does not have SEEK support.

    Signed-off-by: Anna Schumaker
    Signed-off-by: Trond Myklebust

    Anna Schumaker
     

13 Jul, 2014

1 commit

  • The current CB_COMPOUND handling code tries to compare the principal
    name of the request with the cl_hostname in the client. This is not
    guaranteed to ever work, particularly if the client happened to mount
    a CNAME of the server or a non-fqdn.

    Fix this by instead comparing the cr_principal string with the acceptor
    name that we get from gssd. In the event that gssd didn't send one
    down (i.e. it was too old), then we fall back to trying to use the
    cl_hostname as we do today.

    Signed-off-by: Jeff Layton
    Signed-off-by: Trond Myklebust

    Jeff Layton
     

29 Oct, 2013

3 commits


02 Oct, 2013

1 commit


07 Sep, 2013

1 commit

  • Commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible"
    uses the nfs_client cl_rpcclient for all state management operations, and
    will use krb5i or auth_sys with no regard to the mount command authflavor
    choice.

    The MDS, as any NFSv4.1 mount point, uses the nfs_server rpc client for all
    non-state management operations with a different nfs_server for each fsid
    encountered traversing the mount point, each with a potentially different
    auth flavor.

    pNFS data servers are not mounted in the normal sense as there is no associated
    nfs_server structure. Data servers can also export multiple fsids, each with
    a potentially different auth flavor.

    Data servers need to use the same authflavor as the MDS server rpc client for
    non-state management operations. Populate a list of rpc clients with the MDS
    server rpc client auth flavor for the DS to use.

    Signed-off-by: Andy Adamson
    Signed-off-by: Trond Myklebust

    Andy Adamson
     

05 Sep, 2013

5 commits


04 Sep, 2013

1 commit


09 Jun, 2013

3 commits

  • This patch implements the client transport and handling support for labeled
    NFS. The patch adds two functions to encode and decode the security label
    recommended attribute which makes use of the LSM hooks added earlier. It also
    adds code to grab the label from the file attribute structures and encode the
    label to be sent back to the server.

    Acked-by: James Morris
    Signed-off-by: Matthew N. Dodd
    Signed-off-by: Miguel Rodel Felipe
    Signed-off-by: Phua Eu Gene
    Signed-off-by: Khin Mi Mi Aung
    Signed-off-by: Steve Dickson
    Signed-off-by: Trond Myklebust

    David Quigley
     
  • The fattr handling bitmap code only uses the first two fattr words sofar. This
    patch adds the 3rd word to being sent but doesn't populate it yet.

    Signed-off-by: Miguel Rodel Felipe
    Signed-off-by: Phua Eu Gene
    Signed-off-by: Khin Mi Mi Aung
    Signed-off-by: Trond Myklebust

    David Quigley
     
  • This patch adds several new flags to allow the NFS client and server to
    determine if this attribute is supported and if it is being sent over the wire.

    Signed-off-by: Matthew N. Dodd
    Signed-off-by: Miguel Rodel Felipe
    Signed-off-by: Phua Eu Gene
    Signed-off-by: Khin Mi Mi Aung
    Signed-off-by: Trond Myklebust

    David Quigley
     

15 Apr, 2013

1 commit


26 Mar, 2013

2 commits


06 Dec, 2012

5 commits


27 Nov, 2012

1 commit


21 Nov, 2012

1 commit


02 Oct, 2012

2 commits

  • "Server trunking" is a fancy named for a multi-homed NFS server.
    Trunking might occur if a client sends NFS requests for a single
    workload to multiple network interfaces on the same server. There
    are some implications for NFSv4 state management that make it useful
    for a client to know if a single NFSv4 server instance is
    multi-homed. (Note this is only a consideration for NFSv4, not for
    legacy versions of NFS, which are stateless).

    If a client cares about server trunking, no NFSv4 operations can
    proceed until that client determines who it is talking to. Thus
    server IP trunking discovery must be done when the client first
    encounters an unfamiliar server IP address.

    The nfs_get_client() function walks the nfs_client_list and matches
    on server IP address. The outcome of that walk tells us immediately
    if we have an unfamiliar server IP address. It invokes
    nfs_init_client() in this case. Thus, nfs4_init_client() is a good
    spot to perform trunking discovery.

    Discovery requires a client to establish a fresh client ID, so our
    client will now send SETCLIENTID or EXCHANGE_ID as the first NFS
    operation after a successful ping, rather than waiting for an
    application to perform an operation that requires NFSv4 state.

    The exact process for detecting trunking is different for NFSv4.0 and
    NFSv4.1, so a minorversion-specific init_client callout method is
    introduced.

    CLID_INUSE recovery is important for the trunking discovery process.
    CLID_INUSE is a sign the server recognizes the client's nfs_client_id4
    id string, but the client is using the wrong principal this time for
    the SETCLIENTID operation. The SETCLIENTID must be retried with a
    series of different principals until one works, and then the rest of
    trunking discovery can proceed.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Currently, the Linux client uses a unique nfs_client_id4.id string
    when identifying itself to distinct NFS servers.

    To support transparent state migration, the Linux client will have to
    use the same nfs_client_id4 string for all servers it communicates
    with (also known as the "uniform client string" approach). Otherwise
    NFS servers can not recognize that open and lock state need to be
    merged after a file system transition.

    Unfortunately, there are some NFSv4.0 servers currently in the field
    that do not tolerate the uniform client string approach.

    Thus, by default, our NFSv4.0 mounts will continue to use the current
    approach, and we introduce a mount option that switches them to use
    the uniform model. Client administrators must identify which servers
    can be mounted with this option. Eventually most NFSv4.0 servers will
    be able to handle the uniform approach, and we can change the default.

    The first mount of a server controls the behavior for all subsequent
    mounts for the lifetime of that set of mounts of that server. After
    the last mount of that server is gone, the client erases the data
    structure that tracks the lease. A subsequent lease may then honor
    a different "migration" setting.

    This patch adds only the infrastructure for parsing the new mount
    option. Support for uniform client strings is added in a subsequent
    patch.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

31 Jul, 2012

2 commits

  • This patch exports symbols needed by the v4 module. In addition, I also
    switch over to using IS_ENABLED() to check if CONFIG_NFS_V4 or
    CONFIG_NFS_V4_MODULE are set.

    The module (nfs4.ko) will be created in the same directory as nfs.ko and
    will be automatically loaded the first time you try to mount over NFS v4.

    Signed-off-by: Bryan Schumaker
    Signed-off-by: Trond Myklebust

    Bryan Schumaker
     
  • This patch adds in the code to track multiple versions of the NFS
    protocol. I created default structures for v2, v3 and v4 so that each
    version can continue to work while I convert them into kernel modules.
    I also removed the const parameter from the rpc_version array so that I
    can change it at runtime.

    Signed-off-by: Bryan Schumaker
    Signed-off-by: Trond Myklebust

    Bryan Schumaker
     

17 Jul, 2012

1 commit

  • For NFSv4 minor version 0, currently the cl_id_uniquifier allows the
    Linux client to generate a unique nfs_client_id4 string whenever a
    server replies with NFS4ERR_CLID_INUSE.

    This implementation seems to be based on a flawed reading of RFC
    3530. NFS4ERR_CLID_INUSE actually means that the client has presented
    this nfs_client_id4 string with a different principal at some time in
    the past, and that lease is still in use on the server.

    For a Linux client this might be rather difficult to achieve: the
    authentication flavor is named right in the nfs_client_id4.id
    string. If we change flavors, we change strings automatically.

    So, practically speaking, NFS4ERR_CLID_INUSE means there is some other
    client using our string. There is not much that can be done to
    recover automatically. Let's make it a permanent error.

    Remove the recovery logic in nfs4_proc_setclientid(), and remove the
    cl_id_uniquifier field from the nfs_client data structure. And,
    remove the authentication flavor from the nfs_client_id4 string.

    Keeping the authentication flavor in the nfs_client_id4.id string
    means that we could have a separate lease for each authentication
    flavor used by mounts on the client. But we want just one lease for
    all the mounts on this client.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

18 Jun, 2012

1 commit

  • Currently there is a 'chicken and egg' issue when the DS is also the mounted
    MDS. The nfs_match_client() reference from nfs4_set_ds_client bumps the
    cl_count, the nfs_client is not freed at umount, and nfs4_deviceid_purge_client
    is not called to dereference the MDS usage of a deviceid which holds a
    reference to the DS nfs_client. The result is the umount program returns,
    but the nfs_client is not freed, and the cl_session hearbeat continues.

    The MDS (and all other nfs mounts) lose their last nfs_client reference in
    nfs_free_server when the last nfs_server (fsid) is umounted.
    The file layout DS lose their last nfs_client reference in destroy_ds
    when the last deviceid referencing the data server is put and destroy_ds is
    called. This is triggered by a call to nfs4_deviceid_purge_client which
    removes references to a pNFS deviceid used by an MDS mount.

    The fix is to track how many pnfs enabled filesystems are mounted from
    this server, and then to purge the device id cache once that count reaches
    zero.

    Reported-by: Jorge Mora
    Reported-by: Andy Adamson
    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

23 May, 2012

5 commits

  • Save the server major and minor ID results from EXCHANGE_ID, as they
    are needed for detecting server trunking.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • "noresvport" and "discrtry" can be passed to nfs_create_rpc_client()
    by setting flags in the passed-in nfs_client. This change makes it
    easy to add new flags.

    Note that these settings are now "sticky" over the lifetime of a
    struct nfs_client, and may even be copied when an nfs_client is
    cloned.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Currently our NFS client assigns a unique SETCLIENTID boot verifier
    for each server IP address it knows about. It's set to CURRENT_TIME
    when the struct nfs_client for that server IP is created.

    During the SETCLIENTID operation, our client also presents an
    nfs_client_id4 string to servers, as an identifier on which the server
    can hang all of this client's NFSv4 state. Our client's
    nfs_client_id4 string is unique for each server IP address.

    An NFSv4 server is obligated to wipe all NFSv4 state associated with
    an nfs_client_id4 string when the client presents the same
    nfs_client_id4 string along with a changed SETCLIENTID boot verifier.

    When our client unmounts the last of a server's shares, it destroys
    that server's struct nfs_client. The next time the client mounts that
    NFS server, it creates a fresh struct nfs_client with a fresh boot
    verifier. On seeing the fresh verifer, the server wipes any previous
    NFSv4 state associated with that nfs_client_id4.

    However, NFSv4.1 clients are supposed to present the same
    nfs_client_id4 string to all servers. And, to support Transparent
    State Migration, the same nfs_client_id4 string should be presented
    to all NFSv4.0 servers so they recognize that migrated state for this
    client belongs with state a server may already have for this client.
    (This is known as the Uniform Client String model).

    If the nfs_client_id4 string is the same but the boot verifier changes
    for each server IP address, SETCLIENTID and EXCHANGE_ID operations
    from such a client could unintentionally result in a server wiping a
    client's previously obtained lease.

    Thus, if our NFS client is going to use a fixed nfs_client_id4 string,
    either for NFSv4.0 or NFSv4.1 mounts, our NFS client should use a
    boot verifier that does not change depending on server IP address.
    Replace our current per-nfs_client boot verifier with a per-nfs_net
    boot verifier.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Clean up: When naming fields and data types, follow established
    conventions to facilitate accurate grep/cscope searches.

    Introduced by commit e50a7a1a "NFS: make NFS client allocated per
    network namespace context," Tue Jan 10, 2012.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Clean up: When naming fields and data types, follow established
    conventions to facilitate accurate grep/cscope searches.

    Additionally, for consistency, move the impl_id field into the NFSv4-
    specific part of the nfs_client, and free that memory in the logic
    that shuts down NFSv4 nfs_clients.

    Introduced by commit 7d2ed9ac "NFSv4: parse and display server
    implementation ids," Fri Feb 17, 2012.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever