1. 23 Dec, 2008 13 commits
    • Chuck Lever's avatar
      NFS: add "[no]resvport" mount option · d740351b
      Chuck Lever authored
      The standard default security setting for NFS is AUTH_SYS.  An NFS
      client connects to NFS servers via a privileged source port and a
      fixed standard destination port (2049).  The client sends raw uid and
      gid numbers to identify users making NFS requests, and the server
      assumes an appropriate authority on the client has vetted these
      values because the source port is privileged.
      
      On Linux, by default in-kernel RPC services use a privileged port in
      the range between 650 and 1023 to avoid using source ports of well-
      known IP services.  Using such a small range limits the number of NFS
      mount points and the number of unique NFS servers to which a client
      can connect concurrently.
      
      An NFS client can use unprivileged source ports to expand the range of
      source port numbers, allowing more concurrent server connections and
      more NFS mount points.  Servers must explicitly allow NFS connections
      from unprivileged ports for this to work.
      
      In the past, bumping the value of the sunrpc.max_resvport sysctl on
      the client would permit the NFS client to use unprivileged ports.
      Bumping this setting also changes the maximum port number used by
      other in-kernel RPC services, some of which still required a port
      number less than 1023.
      
      This is exacerbated by the way source port numbers are chosen by the
      Linux RPC client, which starts at the top of the range and works
      downwards.  It means that bumping the maximum means all RPC services
      requesting a source port will likely get an unprivileged port instead
      of a privileged one.
      
      Changing this setting effects all NFS mount points on a client.  A
      sysadmin could not selectively choose which mount points would use
      non-privileged ports and which could not.
      
      Lastly, this mechanism of expanding the limit on the number of NFS
      mount points was entirely undocumented.
      
      To address the need for the NFS client to use a large range of source
      ports without interfering with the activity of other in-kernel RPC
      services, we introduce a new NFS mount option.  This option explicitly
      tells only the NFS client to use a non-privileged source port when
      communicating with the NFS server for one specific mount point.
      
      This new mount option is called "resvport," like the similar NFS mount
      option on FreeBSD and Mac OS X.  A sister patch for nfs-utils will be
      submitted that documents this new option in nfs(5).
      
      The default setting for this new mount option requires the NFS client
      to use a privileged port, as before.  Explicitly specifying the
      "noresvport" mount option allows the NFS client to use an unprivileged
      source port for this mount point when connecting to the NFS server
      port.
      
      This mount option is supported only for text-based NFS mounts.
      
      [ Sidebar: it is widely known that security mechanisms based on the
        use of privileged source ports are ineffective.  However, the NFS
        client can combine the use of unprivileged ports with the use of
        secure authentication mechanisms, such as Kerberos.  This allows a
        large number of connections and mount points while ensuring a useful
        level of security.
      
        Eventually we may change the default setting for this option
        depending on the security flavor used for the mount.  For example,
        if the mount is using only AUTH_SYS, then the default setting will
        be "resvport;" if the mount is using a strong security flavor such
        as krb5, the default setting will be "noresvport." ]
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      [Trond.Myklebust@netapp.com: Fixed a bug whereby nfs4_init_client()
      was being called with incorrect arguments.]
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d740351b
    • Chuck Lever's avatar
      NFS: move nfs_server flag initialization · 542fcc33
      Chuck Lever authored
      Make it possible for the NFSv4 mount set up logic to pass mount option
      flags down the stack to nfs_create_rpc_client().
      
      This is immediately useful if we want NFS mount options to modulate
      settings of the underlying RPC transport, but it may be useful at some
      later point if other parts of the NFSv4 mount initialization logic
      want to know what the mount options are.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      542fcc33
    • Chuck Lever's avatar
      NFS: expand flags passed to nfs_create_rpc_client() · 4a01b8a4
      Chuck Lever authored
      The nfs_create_rpc_client() function sets up an RPC client for an NFS
      mount point.  Add an option that allows it to set up an RPC transport
      from an unprivileged port.
      
      Instead of having nfs_create_rpc_client()'s callers retain local
      knowledge about how to set up an RPC client, create a couple of flag
      arguments to control the use of RPC_CLNT_CREATE flags.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      4a01b8a4
    • Chuck Lever's avatar
      NFS: introduce nfs_mount_info struct for calling nfs_mount() · c5d120f8
      Chuck Lever authored
      Clean up: convert nfs_mount() to take a single data structure argument to make
      it simpler to add more arguments.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      c5d120f8
    • Chuck Lever's avatar
      NFS: Move declaration of nfs_mount() to fs/nfs/internal.h · 146ec944
      Chuck Lever authored
      Clean up:  The nfs_mount() function is not to be used outside of the
      NFS client.  Move its public declaration to fs/nfs/internal.h.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      146ec944
    • Chuck Lever's avatar
      NFS: rename nfs_path variable · 7b5d2b98
      Chuck Lever authored
      Clean up: I'm about to move the declaration of nfs_mount into
      fs/nfs/internal.h and include it in fs/nfs/nfsroot.c.  There's a
      conflicting definition of nfs_path in fs/nfs/internal.h and
      fs/nfs/nfsroot.c, so rename the private one.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      7b5d2b98
    • Jeff Layton's avatar
      lockd: convert reclaimer thread to kthread interface · df94f000
      Jeff Layton authored
      My understanding is that there is a push to turn the kernel_thread
      interface into a non-exported symbol and move all kernel threads to use
      the kthread API. This patch changes lockd to use kthread_run to spawn
      the reclaimer thread.
      
      I've made the assumption here that the extra module references taken
      when we spawn this thread are unnecessary and removed them. I've also
      added a KERN_ERR printk that pops if the thread can't be spawned to warn
      the admin that the locks won't be reclaimed.
      
      In the future, it would be nice to be able to notify userspace that
      locks have been lost (probably by implementing SIGLOST), and adding some
      good policies about how long we should reattempt to reclaim the locks.
      
      Finally, I removed a comment about memory leaks that I believe is
      obsolete and added a new one to clarify the result of sending a SIGKILL
      to the reclaimer thread. As best I can tell, doing so doesn't actually
      cause a memory leak.
      
      I consider this patch 2.6.29 material.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      df94f000
    • Trond Myklebust's avatar
    • Trond Myklebust's avatar
      SUNRPC: nfsacl_encode/nfsacl_decode should be exported as GPL-only · d716f0b8
      Trond Myklebust authored
      Again, this has never been intended as a public abi for out-of-tree
      modules.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      d716f0b8
    • Trond Myklebust's avatar
    • Trond Myklebust's avatar
      SUNRPC: Convert the xdr helpers and rpc_pipefs to EXPORT_SYMBOL_GPL · 468039ee
      Trond Myklebust authored
      We've never considered the sunrpc code as part of any ABI to be used by
      out-of-tree modules.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      468039ee
    • Trond Myklebust's avatar
      SUNRPC: Remove the last remnant of the BKL... · 88a9fe8c
      Trond Myklebust authored
      Somehow, this escaped the previous purge. There should be no need to keep
      any extra locks in the XDR callbacks.
      
      The NFS client XDR code only writes into private objects, whereas all reads
      of shared objects are confined to fields that do not change, such as
      filehandles...
      
      Ditto for lockd, the NFSv2/v3 client mount code, and rpcbind.
      
      The nfsd XDR code may require the BKL, but since it does a synchronous RPC
      call from a thread that already holds the lock, that issue is moot.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      88a9fe8c
    • Wu Fengguang's avatar
      nfs: remove redundant tests on reading new pages · 136221fc
      Wu Fengguang authored
      aops->readpages() and its NFS helper readpage_async_filler() will only
      be called to do readahead I/O for newly allocated pages. So it's not
      necessary to test for the always 0 dirty/uptodate page flags.
      
      The removal of nfs_wb_page() call also fixes a readahead bug: the NFS
      readahead has been synchronous since 2.6.23, because that call will
      clear PG_readahead, which is the reminder for asynchronous readahead.
      
      More background: the PG_readahead page flag is shared with PG_reclaim,
      one for read path and the other for write path. clear_page_dirty_for_io()
      unconditionally clears PG_readahead to prevent possible readahead residuals,
      assuming itself to be always called in the write path. However, NFS is one
      and the only exception in that it _always_ calls clear_page_dirty_for_io()
      in the read path, i.e. for readpages()/readpage().
      
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: default avatarWu Fengguang <wfg@linux.intel.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      136221fc
  2. 20 Dec, 2008 4 commits
  3. 19 Dec, 2008 20 commits
  4. 18 Dec, 2008 3 commits