1. 02 Mar, 2012 5 commits
    • Chuck Lever's avatar
      NFS: Clean up debugging in decode_pathname() · 02a2976c
      Chuck Lever authored
      I noticed recently that decode_attr_fs_locations() is not generating
      very pretty debugging output.  The pathname components each appear on
      a separate line of output, though that does not appear to be the
      intended display behavior.  The preferred way to generate continued
      lines of output on the console is to use pr_cont().
      
      Note that incoming pathname4 components contain a string that is not
      necessarily NUL-terminated.  I did actually see some trailing garbage
      on the console.  In addition to correcting the line continuation
      problem, add a string precision format specifier to ensure that each
      component string is displayed properly, and that vsnprintf() does
      not Oops.
      
      Someone pointed out that allowing incoming network data to possibly
      generate a console line of unbounded length may not be such a good
      idea.  Since this output will rarely be enabled, and there is a hard
      upper bound (NFS4_PATHNAME_MAXCOMPONENTS) in our implementation, this
      is probably not a major concern.
      
      It might be useful to additionally sanity-check the length of each
      incoming component, however.  RFC 3530bis15 does not suggest a maximum
      number of UTF-8 characters per component for either the pathname4 or
      component4 types.  However, we could invent one that is appropriate
      for our implementation.
      
      Another possibility is to scrap all of this and print these pathnames
      in upper layers after a reasonable amount of sanity checking in the
      XDR layer.  This would give us an opportunity to allocate a full
      buffer so that the whole pathname would be output via a single
      dprintk.
      
      Introduced by commit 7aaa0b3b: "NFSv4: convert fs-locations-components
      to conform to RFC3530," (June 9, 2006).
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      02a2976c
    • Chuck Lever's avatar
      NFS: Make nfs_cache_array.size a signed integer · 88b8e133
      Chuck Lever authored
      Eliminate a number of implicit type casts in comparisons, and these
      compiler warnings:
      
      fs/nfs/dir.c: In function ‘nfs_readdir_clear_array’:
      fs/nfs/dir.c:264:16: warning: comparison between signed and unsigned
      		integer expressions [-Wsign-compare]
      fs/nfs/dir.c: In function ‘nfs_readdir_search_for_cookie’:
      fs/nfs/dir.c:352:16: warning: comparison between signed and unsigned
      		integer expressions [-Wsign-compare]
      fs/nfs/dir.c: In function ‘nfs_do_filldir’:
      fs/nfs/dir.c:769:38: warning: comparison between signed and unsigned
      		integer expressions [-Wsign-compare]
      fs/nfs/dir.c:780:9: warning: comparison between signed and unsigned
      		integer expressions [-Wsign-compare]
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      88b8e133
    • Trond Myklebust's avatar
    • Trond Myklebust's avatar
      NFS: Ensure we display the minor version correctly in /proc/mounts etc. · 7bbceb6f
      Trond Myklebust authored
      The 'minorversion' mount option is now deprecated, so we need to display
      the minor version number in the 'vers=' format.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      7bbceb6f
    • Trond Myklebust's avatar
      NFS: Extend the -overs= mount option to allow 4.x minorversions · 0d71b058
      Trond Myklebust authored
      Allow the user to mount an NFSv4.0 or NFSv4.1 partition using a
      standard syntax of '-overs=4.0', or '-overs=4.1' rather than the
      more cumbersome '-overs=4,minorversion=1'.
      
      See also the earlier patch by Dros Adamson, which added the
      Linux-specific syntax '-ov4.0', '-ov4.1'.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      0d71b058
  2. 01 Mar, 2012 7 commits
  3. 27 Feb, 2012 4 commits
    • Stanislav Kinsbursky's avatar
      SUNRPC: move waitq from RPC pipe to RPC inode · 591ad7fe
      Stanislav Kinsbursky authored
      Currently, wait queue, used for polling of RPC pipe changes from user-space,
      is a part of RPC pipe. But the pipe data itself can be released on NFS umount
      prior to dentry-inode pair, connected to it (is case of this pair is open by
      some process).
      This is not a problem for almost all pipe users, because all PipeFS file
      operations checks pipe reference prior to using it.
      Except evenfd. This thing registers itself with "poll" file operation and thus
      has a reference to pipe wait queue. This leads to oopses on destroying eventfd
      after NFS umount (like rpc_idmapd do) since not pipe data left to the point
      already.
      The solution is to wait queue from pipe data to internal RPC inode data. This
      looks more logical, because this wiat queue used only for user-space processes,
      which already holds inode reference.
      
      Note: upcalls have to get pipe->dentry prior to dereferecing wait queue to make
      sure, that mount point won't disappear from underneath us.
      Signed-off-by: default avatarStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      591ad7fe
    • Stanislav Kinsbursky's avatar
      SUNRPC: check RPC inode's pipe reference before dereferencing · 2c9030ee
      Stanislav Kinsbursky authored
      There are 2 tightly bound objects: pipe data (created for kernel needs, has
      reference to dentry, which depends on PipeFS mount/umount) and PipeFS
      dentry/inode pair (created on mount for user-space needs). They both
      independently may have or have not a valid reference to each other.
      This means, that we have to make sure, that pipe->dentry reference is valid on
      upcalls, and dentry->pipe reference is valid on downcalls. The latter check is
      absent - my fault.
      IOW, PipeFS dentry can be opened by some process (rpc.idmapd for example), but
      it's pipe data can belong to NFS mount, which was unmounted already and thus
      pipe data was destroyed.
      To fix this, pipe reference have to be set to NULL on rpc_unlink() and checked
      on PipeFS file operations instead of pipe->dentry check.
      
      Note: PipeFS "poll" file operation will be updated in next patch, because it's
      logic is more complicated.
      Signed-off-by: default avatarStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      2c9030ee
    • Stanislav Kinsbursky's avatar
      NFS: release per-net clients lock before calling PipeFS dentries creation · e9dbca8d
      Stanislav Kinsbursky authored
      v3:
      1) Lookup for client is performed from the beginning of the list on each PipeFS
      event handling operation.
      
      Lockdep is sad otherwise, because inode mutex is taken on PipeFS dentry
      creation, which can be called on mount notification, where this per-net client
      lock is taken on clients list walk.
      Signed-off-by: default avatarStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      e9dbca8d
    • Stanislav Kinsbursky's avatar
      SUNRPC: release per-net clients lock before calling PipeFS dentries creation · da3b4622
      Stanislav Kinsbursky authored
      v3:
      1) Lookup for client is performed from the beginning of the list on each PipeFS
      event handling operation.
      
      Lockdep is sad otherwise, because inode mutex is taken on PipeFS dentry
      creation, which can be called on mount notification, where this per-net client
      lock is taken on clients list walk.
      Signed-off-by: default avatarStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      da3b4622
  4. 26 Feb, 2012 1 commit
  5. 19 Feb, 2012 2 commits
  6. 17 Feb, 2012 2 commits
  7. 16 Feb, 2012 4 commits
  8. 15 Feb, 2012 15 commits