Skip to content
  1. Jul 28, 2012
  2. Jul 27, 2012
  3. Jul 25, 2012
  4. Jul 12, 2012
    • NeilBrown's avatar
      SUNRPC/cache: fix reporting of expired cache entries in 'content' file. · 200724a7
      NeilBrown authored
      
      
      Entries that are in a sunrpc cache but are not valid should be reported
      with a leading '#' so they look like a comment.
      Commit  d202cce8 (sunrpc: never return expired entries in sunrpc_cache_lookup)
      broke this for expired entries.
      
      This particularly applies to entries that have been replaced by newer entries.
      sunrpc_cache_update sets the expiry of the replaced entry to '0', but it
      remains in the cache until the next 'cache_clean'.
      The result is that if you
      
        echo 0 2000000000 1 0 > /proc/net/rpc/auth.unix.gid/channel
      
      several times, then
      
        cat /proc/net/rpc/auth.unix.gid/content
      
      It will display multiple entries for the one uid, which is at least confusing:
      
        #uid cnt: gids...
        0 1: 0
        0 1: 0
        0 1: 0
      
      With this patch, expired entries are marked as comments so you get
      
        #uid cnt: gids...
        0 1: 0
        # 0 1: 0
        # 0 1: 0
      
      These expired entries will never be seen by cache_check() as they are always
      *after* a non-expired entry with the same key - so the extra check is only
      needed in c_show()
      
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      
      --
      It's not a big problem, but it had me confused for a while, so it could
      well confuse others.
      Thanks,
      NeilBrown
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      200724a7
    • Eldad Zack's avatar
      sunrpc/cache.h: replace simple_strtoul · bbf43dc8
      Eldad Zack authored
      
      
      This patch replaces the usage of simple_strtoul with kstrtoint in
      get_int(), since the simple_str* family doesn't account for overflow
      and is deprecated.
      Also, in this specific case, the long from strtol is silently converted
      to an int by the caller.
      
      As Joe Perches <joe@perches.com> suggested, this patch also removes
      the redundant temporary variable rv, since kstrtoint() will not write to
      anint unless it's successful.
      
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarEldad Zack <eldad@fogrefinery.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      bbf43dc8
    • Eldad Zack's avatar
      sunrpc/cache.h: fix coding style · d9c2ede6
      Eldad Zack authored
      
      
      Neaten code style in get_int().
      Also use sizeof() instead of hard coded number as suggested by
      Joe Perches <joe@perches.com>.
      
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarEldad Zack <eldad@fogrefinery.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      d9c2ede6
  5. Jul 11, 2012
    • J. Bruce Fields's avatar
      nfsd: share some function prototypes · 7f2e7dc0
      J. Bruce Fields authored
      
      
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      7f2e7dc0
    • J. Bruce Fields's avatar
      nfsd: allow owner_override only for regular files · d91d0b56
      J. Bruce Fields authored
      
      
      We normally allow the owner of a file to override permissions checks on
      IO operations, since:
      	- the client will take responsibility for doing an access check
      	  on open;
      	- the permission checks offer no protection against malicious
      	  clients--if they can authenticate as the file's owner then
      	  they can always just change its permissions;
      	- checking permission on each IO operation breaks the usual
      	  posix rule that permission is checked only on open.
      
      However, we've never allowed the owner to override permissions on
      readdir operations, even though the above logic would also apply to
      directories.  I've never heard of this causing a problem, probably
      because a) simultaneously opening and creating a directory (with
      restricted mode) isn't possible, and b) opening a directory, then
      chmod'ing it, is rare.
      
      Our disallowal of owner-override on directories appears to be an
      accident, though--the readdir itself succeeds, and then we fail just
      because lookup_one_len() calls in our filldir methods fail.
      
      I'm not sure what the easiest fix for that would be.  For now, just make
      this behavior obvious by denying the override right at the start.
      
      This also fixes some odd v4 behavior: with the rdattr_error attribute
      requested, it would perform the readdir but return an ACCES error with
      each entry.
      
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      d91d0b56
    • J. Bruce Fields's avatar
      nfsd4: release openowners on free in >=4.1 case · 74dbafaf
      J. Bruce Fields authored
      
      
      We don't need to keep openowners around in the >=4.1 case, because they
      aren't needed to handle CLOSE replays any more (that's a problem for
      sessions).  And doing so causes unexpected failures on a subsequent
      destroy_clientid to fail.
      
      We probably also need something comparable for lock owners on last
      unlock.
      
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      74dbafaf
    • J. Bruce Fields's avatar
      nfsd4: our filesystems are normally case sensitive · 2930d381
      J. Bruce Fields authored
      
      
      Actually, xfs and jfs can optionally be case insensitive; we'll handle
      that case in later patches.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      2930d381
  6. Jun 20, 2012
    • J. Bruce Fields's avatar
      nfsd4: process_open2 cleanup · 4af82504
      J. Bruce Fields authored
      
      
      Note we can simplify the error handling a little by doing the truncate
      earlier.
      
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      4af82504
    • J. Bruce Fields's avatar
      nfsd4: nfsd4_lock() cleanup · e1aaa891
      J. Bruce Fields authored
      
      
      Share a little common logic.  And note the comments here are a little
      out of date (e.g. we don't always create new state in the "new" case any
      more.)
      
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      e1aaa891
    • J. Bruce Fields's avatar
      nfsd4: remove unnecessary comment · 9068bed1
      J. Bruce Fields authored
      
      
      For the most part readers of cl_cb_state only need a value that is
      "eventually" right.  And the value is set only either 1) in response to
      some change of state, in which case it's set to UNKNOWN and then a
      callback rpc is sent to probe the real state, or b) in the handling of a
      response to such a callback.  UNKNOWN is therefore always a "temporary"
      state, and for the other states we're happy to accept last writer wins.
      
      So I think we're OK here.
      
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      9068bed1
    • Chuck Lever's avatar
      NFSD: TEST_STATEID should not return NFS4ERR_STALE_STATEID · 7df302f7
      Chuck Lever authored
      
      
      According to RFC 5661, the TEST_STATEID operation is not allowed to
      return NFS4ERR_STALE_STATEID.  In addition, RFC 5661 says:
      
      15.1.16.5.  NFS4ERR_STALE_STATEID (Error Code 10023)
      
         A stateid generated by an earlier server instance was used.  This
         error is moot in NFSv4.1 because all operations that take a stateid
         MUST be preceded by the SEQUENCE operation, and the earlier server
         instance is detected by the session infrastructure that supports
         SEQUENCE.
      
      I triggered NFS4ERR_STALE_STATEID while testing the Linux client's
      NOGRACE recovery.  Bruce suggested an additional test that could be
      useful to client developers.
      
      Lastly, RFC 5661, section 18.48.3 has this:
      
       o  Special stateids are always considered invalid (they result in the
          error code NFS4ERR_BAD_STATEID).
      
      An explicit check is made for those state IDs to avoid printk noise.
      
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      7df302f7
    • Weston Andros Adamson's avatar
      nfsd: probe the back channel on new connections · 24119673
      Weston Andros Adamson authored
      
      
      Initiate a CB probe when a new connection with the correct direction is added
      to a session (IFF backchannel is marked as down).  Without this a
      BIND_CONN_TO_SESSION has no effect on the internal backchannel state, which
      causes the server to reply to every SEQUENCE op with the
      SEQ4_STATUS_CB_PATH_DOWN flag set until DESTROY_SESSION.
      
      Signed-off-by: default avatarWeston Andros Adamson <dros@netapp.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      24119673
  7. Jun 19, 2012