1. 01 8月, 2014 2 次提交
  2. 30 7月, 2014 13 次提交
  3. 24 7月, 2014 7 次提交
  4. 23 7月, 2014 2 次提交
    • C
      svcrdma: Add zero padding if the client doesn't send it · e560e3b5
      Chuck Lever 提交于
      See RFC 5666 section 3.7: clients don't have to send zero XDR
      padding.
      
      BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=246Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      e560e3b5
    • J
      nfsd: bump dl_time when unhashing delegation · d55a166c
      Jeff Layton 提交于
      There's a potential race between a lease break and DELEGRETURN call.
      
      Suppose a lease break comes in and queues the workqueue job for a
      delegation, but it doesn't run just yet. Then, a DELEGRETURN comes in
      finds the delegation and calls destroy_delegation on it to unhash it and
      put its primary reference.
      
      Next, the workqueue job runs and queues the delegation back onto the
      del_recall_lru list, issues the CB_RECALL and puts the final reference.
      With that, the final reference to the delegation is put, but it's still
      on the LRU list.
      
      When we go to unhash a delegation, it's because we intend to get rid of
      it soon afterward, so we don't want lease breaks to mess with it once
      that occurs. Fix this by bumping the dl_time whenever we unhash a
      delegation, to ensure that lease breaks don't monkey with it.
      
      I believe this is a regression due to commit 02e1215f (nfsd: Avoid
      taking state_lock while holding inode lock in nfsd_break_one_deleg).
      Prior to that, the state_lock was held in the lm_break callback itself,
      and that would have prevented this race.
      
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      d55a166c
  5. 22 7月, 2014 3 次提交
  6. 18 7月, 2014 4 次提交
  7. 17 7月, 2014 4 次提交
  8. 12 7月, 2014 3 次提交
  9. 11 7月, 2014 2 次提交
    • J
      nfsd: cleanup and rename nfs4_check_open · a46cb7f2
      Jeff Layton 提交于
      Rename it to better describe what it does, and have it just return the
      stateid instead of a __be32 (which is now always nfs_ok). Also, do the
      search for an existing stateid after the delegation check, to reduce
      cleanup if the delegation check returns error.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      a46cb7f2
    • J
      nfsd: make deny mode enforcement more efficient and close races in it · baeb4ff0
      Jeff Layton 提交于
      The current enforcement of deny modes is both inefficient and scattered
      across several places, which makes it hard to guarantee atomicity. The
      inefficiency is a problem now, and the lack of atomicity will mean races
      once the client_mutex is removed.
      
      First, we address the inefficiency. We have to track deny modes on a
      per-stateid basis to ensure that open downgrades are sane, but when the
      server goes to enforce them it has to walk the entire list of stateids
      and check against each one.
      
      Instead of doing that, maintain a per-nfs4_file deny mode. When a file
      is opened, we simply set any deny bits in that mode that were specified
      in the OPEN call. We can then use that unified deny mode to do a simple
      check to see whether there are any conflicts without needing to walk the
      entire stateid list.
      
      The only time we'll need to walk the entire list of stateids is when a
      stateid that has a deny mode on it is being released, or one is having
      its deny mode downgraded. In that case, we must walk the entire list and
      recalculate the fi_share_deny field. Since deny modes are pretty rare
      today, this should be very rare under normal workloads.
      
      To address the potential for races once the client_mutex is removed,
      protect fi_share_deny with the fi_lock. In nfs4_get_vfs_file, check to
      make sure that any deny mode we want to apply won't conflict with
      existing access. If that's ok, then have nfs4_file_get_access check that
      new access to the file won't conflict with existing deny modes.
      
      If that also passes, then get file access references, set the correct
      access and deny bits in the stateid, and update the fi_share_deny field.
      If opening the file or truncating it fails, then unwind the whole mess
      and return the appropriate error.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      baeb4ff0