1. 05 Jan, 2012 6 commits
    • Andy Adamson's avatar
      NFSv4.1: cleanup init and reset of session slot tables · aacd5537
      Andy Adamson authored
      We are either initializing or resetting a session. Initialize or reset
      the session slot tables accordingly.
      Signed-off-by: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      aacd5537
    • Andy Adamson's avatar
      NFSv4.1: fix backchannel slotid off-by-one bug · 61f2e510
      Andy Adamson authored
      Cc:stable@kernel.org
      Signed-off-by: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      61f2e510
    • Jeff Layton's avatar
      nfs: fix regression in handling of context= option in NFSv4 · 8a0d551a
      Jeff Layton authored
      Setting the security context of a NFSv4 mount via the context= mount
      option is currently broken. The NFSv4 codepath allocates a parsed
      options struct, and then parses the mount options to fill it. It
      eventually calls nfs4_remote_mount which calls security_init_mnt_opts.
      That clobbers the lsm_opts struct that was populated earlier. This bug
      also looks like it causes a small memory leak on each v4 mount where
      context= is used.
      
      Fix this by moving the initialization of the lsm_opts into
      nfs_alloc_parsed_mount_data. Also, add a destructor for
      nfs_parsed_mount_data to make it easier to free all of the allocations
      hanging off of it, and to ensure that the security_free_mnt_opts is
      called whenever security_init_mnt_opts is.
      
      I believe this regression was introduced quite some time ago, probably
      by commit c02d7adf.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      8a0d551a
    • NeilBrown's avatar
      NFS - fix recent breakage to NFS error handling. · 2edb6bc3
      NeilBrown authored
      From c6d615d2b97fe305cbf123a8751ced859dca1d5e Mon Sep 17 00:00:00 2001
      From: NeilBrown <neilb@suse.de>
      Date: Wed, 16 Nov 2011 09:39:05 +1100
      Subject: [PATCH] NFS - fix recent breakage to NFS error handling.
      
      commit 02c24a82 made a small and
      presumably unintended change to write error handling in NFS.
      
      Previously an error from filemap_write_and_wait_range would only be of
      interest if nfs_file_fsync did not return an error.  After this commit,
      an error from filemap_write_and_wait_range would mean that (the rest of)
      nfs_file_fsync would not even be called.
      
      This means that:
       1/ you are more likely to see EIO than e.g. EDQUOT or ENOSPC.
       2/ NFS_CONTEXT_ERROR_WRITE remains set for longer so more writes are
          synchronous.
      
      This patch restores previous behaviour.
      
      Cc: stable@kernel.org
      Cc: Josef Bacik <josef@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      2edb6bc3
    • Chuck Lever's avatar
      NFS: Retry mounting NFSROOT · 43717c7d
      Chuck Lever authored
      Lukas Razik <linux@razik.name> reports that on his SPARC system,
      booting with an NFS root file system stopped working after commit
      56463e50 "NFS: Use super.c for NFSROOT mount option parsing."
      
      We found that the network switch to which Lukas' client was attached
      was delaying access to the LAN after the client's NIC driver reported
      that its link was up.  The delay was longer than the timeouts used in
      the NFS client during mounting.
      
      NFSROOT worked for Lukas before commit 56463e50 because in those
      kernels, the client's first operation was an rpcbind request to
      determine which port the NFS server was listening on.  When that
      request failed after a long timeout, the client simply selected the
      default NFS port (2049).  By that time the switch was allowing access
      to the LAN, and the mount succeeded.
      
      Neither of these client behaviors is desirable, so reverting 56463e50
      is really not a choice.  Instead, introduce a mechanism that retries
      the NFSROOT mount request several times.  This is the same tactic that
      normal user space NFS mounts employ to overcome server and network
      delays.
      Signed-off-by: default avatarLukas Razik <linux@razik.name>
      [ cel: match kernel coding style, add proper patch description ]
      [ cel: add exponential back-off ]
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarLukas Razik <linux@razik.name>
      Cc: stable@kernel.org # > 2.6.38
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      43717c7d
    • Trond Myklebust's avatar
      SUNRPC: Clean up the RPCSEC_GSS service ticket requests · 68c97153
      Trond Myklebust authored
      Instead of hacking specific service names into gss_encode_v1_msg, we should
      just allow the caller to specify the service name explicitly.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      68c97153
  2. 04 Jan, 2012 13 commits
  3. 03 Jan, 2012 9 commits
  4. 02 Jan, 2012 2 commits
  5. 31 Dec, 2011 6 commits
  6. 30 Dec, 2011 4 commits