1. 04 Oct, 2012 1 commit
  2. 03 Oct, 2012 4 commits
  3. 02 Oct, 2012 16 commits
  4. 01 Oct, 2012 19 commits
    • Trond Myklebust's avatar
      NFSv4: nfs4_match_clientids is only used by NFSv4.1 · f9d640f3
      Trond Myklebust authored
      Fix another compiler warning.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      f9d640f3
    • Trond Myklebust's avatar
      NFSv4: Fix the minor version callback channel startup · 758201e2
      Trond Myklebust authored
      The current spaghetti code confuses some versions of gcc (and just
      looks ugly as hell)! Clean up...
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      758201e2
    • Trond Myklebust's avatar
      NFSv4: Fix up a merge conflict between migration and container changes · 9f62387d
      Trond Myklebust authored
      nfs_callback_tcpport is now per-net_namespace.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      9f62387d
    • Trond Myklebust's avatar
      2afdfa5a
    • Daniel Walter's avatar
      nfs: replace strict_strto* with kstrto* · 7297cb68
      Daniel Walter authored
      [nfs] replace strict_str* with kstr* variants
      
       * replace string conversions with newer kstr* functions
      Signed-off-by: default avatarDaniel Walter <sahne@0x90.at>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      7297cb68
    • Yanchuan Nian's avatar
      NFS: Remove unnecessary semicolons (fs/nfs/client.c) · ee34e136
      Yanchuan Nian authored
      There are some unnecessary semicolons in function find_nfs_version. Just remove them.
      Signed-off-by: default avatarYanchuan Nian <ycnian@gmail.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      ee34e136
    • Wei Yongjun's avatar
      pnfsblock: use list_move_tail instead of list_del/list_add_tail · 4e266229
      Wei Yongjun authored
      Using list_move_tail() instead of list_del() + list_add_tail().
      
      spatch with a semantic match is used to found this problem.
      (http://coccinelle.lip6.fr/)
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      4e266229
    • Peng Tao's avatar
      pnfsblock: fix non-aligned DIO write · 96c9eae6
      Peng Tao authored
      For DIO writes, if it is not blocksize aligned, we need to do
      internal serialization. It may slow down writers anyway. So we
      just bail them out and resend to MDS.
      
      Cc: stable <stable@vger.kernel.org> [since v3.4]
      Signed-off-by: default avatarPeng Tao <tao.peng@emc.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      96c9eae6
    • Peng Tao's avatar
      pnfsblock: fix non-aligned DIO read · f742dc4a
      Peng Tao authored
      For DIO read, if it is not sector aligned, we should reject it
      and resend via MDS. Otherwise there might be data corruption.
      Also teach bl_read_pagelist to handle partial page reads for DIO.
      
      Cc: stable <stable@vger.kernel.org> [since v3.4]
      Signed-off-by: default avatarPeng Tao <tao.peng@emc.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      f742dc4a
    • Peng Tao's avatar
      pnfsblock: fix partial page buffer wirte · fe6e1e8d
      Peng Tao authored
      If applications use flock to protect its write range, generic NFS
      will not do read-modify-write cycle at page cache level. Therefore
      LD should know how to handle non-sector aligned writes. Otherwise
      there will be data corruption.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarPeng Tao <tao.peng@emc.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      fe6e1e8d
    • Peng Tao's avatar
      Revert "pnfsblock: bail out partial page IO" · 5d0e3a00
      Peng Tao authored
      This reverts commit 159e0561, in favor
      of a more complete fix to the alignment issue.
      Signed-off-by: default avatarPeng Tao <tao.peng@emc.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      5d0e3a00
    • Peng Tao's avatar
      NFS41: fix error of setting blocklayoutdriver · dc182549
      Peng Tao authored
      After commit e38eb650 (NFS: set_pnfs_layoutdriver() from
      nfs4_proc_fsinfo()), set_pnfs_layoutdriver() is called inside
      nfs4_proc_fsinfo(), but pnfs_blksize is not set. It causes setting
      blocklayoutdriver failure and pnfsblock mount failure.
      
      Cc: stable <stable@vger.kernel.org> [since v3.5]
      Signed-off-by: default avatarPeng Tao <tao.peng@emc.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      dc182549
    • Peng Tao's avatar
      NFSv41: fix DIO write_io calculation · 7acdb026
      Peng Tao authored
      pnfs_within_mdsthreshold() is called inside pg_init. We need to set
      read_io/write_io before that. Otherwise we fail pnfs_within_mdsthreshold()
      and IO goes to MDS.
      A simple test case:
      dd if=foo of=/mnt/pnfs/bar bs=10M count=1 oflag=direct
      Signed-off-by: default avatarPeng Tao <tao.peng@emc.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      7acdb026
    • Chuck Lever's avatar
      NFS: Add nfs4_unique_id boot parameter · 6f2ea7f2
      Chuck Lever authored
      An optional boot parameter is introduced to allow client
      administrators to specify a string that the Linux NFS client can
      insert into its nfs_client_id4 id string, to make it both more
      globally unique, and to ensure that it doesn't change even if the
      client's nodename changes.
      
      If this boot parameter is not specified, the client's nodename is
      used, as before.
      
      Client installation procedures can create a unique string (typically,
      a UUID) which remains unchanged during the lifetime of that client
      instance.  This works just like creating a UUID for the label of the
      system's root and boot volumes.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      6f2ea7f2
    • Chuck Lever's avatar
      NFS: Discover NFSv4 server trunking when mounting · 05f4c350
      Chuck Lever authored
      "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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      05f4c350
    • Chuck Lever's avatar
      NFS: Use the same nfs_client_id4 for every server · e984a55a
      Chuck Lever authored
      Currently, when identifying itself to NFS servers, the Linux NFS
      client uses a unique nfs_client_id4.id string for each server IP
      address it talks with.  For example, when client A talks to server X,
      the client identifies itself using a string like "AX".  The
      requirements for these strings are specified in detail by RFC 3530
      (and bis).
      
      This form of client identification presents a problem for Transparent
      State Migration.  When client A's state on server X is migrated to
      server Y, it continues to be associated with string "AX."  But,
      according to the rules of client string construction above, client
      A will present string "AY" when communicating with server Y.
      
      Server Y thus has no way to know that client A should be associated
      with the state migrated from server X.  "AX" is all but abandoned,
      interfering with establishing fresh state for client A on server Y.
      
      To support transparent state migration, then, NFSv4.0 clients must
      instead use the same nfs_client_id4.id string to identify themselves
      to every NFS server; something like "A".
      
      Now a client identifies itself as "A" to server X.  When a file
      system on server X transitions to server Y, and client A identifies
      itself as "A" to server Y, Y will know immediately that the state
      associated with "A," whether it is native or migrated, is owned by
      the client, and can merge both into a single lease.
      
      As a pre-requisite to adding support for NFSv4 migration to the Linux
      NFS client, this patch changes the way Linux identifies itself to NFS
      servers via the SETCLIENTID (NFSv4 minor version 0) and EXCHANGE_ID
      (NFSv4 minor version 1) operations.
      
      In addition to removing the server's IP address from nfs_client_id4,
      the Linux NFS client will also no longer use its own source IP address
      as part of the nfs_client_id4 string.  On multi-homed clients, the
      value of this address depends on the address family and network
      routing used to contact the server, thus it can be different for each
      server.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      e984a55a
    • Chuck Lever's avatar
      NFS: Introduce "migration" mount option · 89652617
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      89652617
    • Chuck Lever's avatar
      SUNRPC: Introduce rpc_clone_client_set_auth() · ba9b584c
      Chuck Lever authored
      An ULP is supposed to be able to replace a GSS rpc_auth object with
      another GSS rpc_auth object using rpcauth_create().  However,
      rpcauth_create() in 3.5 reliably fails with -EEXIST in this case.
      This is because when gss_create() attempts to create the upcall pipes,
      sometimes they are already there.  For example if a pipe FS mount
      event occurs, or a previous GSS flavor was in use for this rpc_clnt.
      
      It turns out that's not the only problem here.  While working on a
      fix for the above problem, we noticed that replacing an rpc_clnt's
      rpc_auth is not safe, since dereferencing the cl_auth field is not
      protected in any way.
      
      So we're deprecating the ability of rpcauth_create() to switch an
      rpc_clnt's security flavor during normal operation.  Instead, let's
      add a fresh API that clones an rpc_clnt and gives the clone a new
      flavor before it's used.
      
      This makes immediate use of the new __rpc_clone_client() helper.
      
      This can be used in a similar fashion to rpcauth_create() when a
      client is hunting for the correct security flavor.  Instead of
      replacing an rpc_clnt's security flavor in a loop, the ULP replaces
      the whole rpc_clnt.
      
      To fix the -EEXIST problem, any ULP logic that relies on replacing
      an rpc_clnt's rpc_auth with rpcauth_create() must be changed to use
      this API instead.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      ba9b584c
    • Chuck Lever's avatar
      SUNRPC: Refactor rpc_clone_client() · 1b63a751
      Chuck Lever authored
      rpc_clone_client() does most of the same tasks as rpc_new_client(),
      so there is an opportunity for code re-use.  Create a generic helper
      that makes it easy to clone an RPC client while replacing any of the
      clnt's parameters.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      1b63a751