1. 23 1月, 2015 2 次提交
  2. 17 1月, 2015 3 次提交
  3. 16 1月, 2015 1 次提交
  4. 08 1月, 2015 3 次提交
  5. 11 12月, 2014 1 次提交
    • D
      net: replace remaining users of arch_fast_hash with jhash · 87545899
      Daniel Borkmann 提交于
      This patch effectively reverts commit 500f8087 ("net: ovs: use CRC32
      accelerated flow hash if available"), and other remaining arch_fast_hash()
      users such as from nfsd via commit 6282cd56 ("NFSD: Don't hand out
      delegations for 30 seconds after recalling them.") where it has been used
      as a hash function for bloom filtering.
      
      While we think that these users are actually not much of concern, it has
      been requested to remove the arch_fast_hash() library bits that arose
      from [1] entirely as per recent discussion [2]. The main argument is that
      using it as a hash may introduce bias due to its linearity (see avalanche
      criterion) and thus makes it less clear (though we tried to document that)
      when this security/performance trade-off is actually acceptable for a
      general purpose library function.
      
      Lets therefore avoid any further confusion on this matter and remove it to
      prevent any future accidental misuse of it. For the time being, this is
      going to make hashing of flow keys a bit more expensive in the ovs case,
      but future work could reevaluate a different hashing discipline.
      
        [1] https://patchwork.ozlabs.org/patch/299369/
        [2] https://patchwork.ozlabs.org/patch/418756/
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: Francesco Fusco <fusco@ntop.org>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87545899
  6. 10 12月, 2014 8 次提交
  7. 02 12月, 2014 1 次提交
  8. 20 11月, 2014 6 次提交
  9. 08 11月, 2014 3 次提交
  10. 01 11月, 2014 1 次提交
  11. 24 10月, 2014 4 次提交
  12. 21 10月, 2014 1 次提交
  13. 08 10月, 2014 6 次提交
    • J
      locks: give lm_break a return value · 4d01b7f5
      Jeff Layton 提交于
      Christoph suggests:
      
         "Add a return value to lm_break so that the lock manager can tell the
          core code "you can delete this lease right now".  That gets rid of
          the games with the timeout which require all kinds of race avoidance
          code in the users."
      
      Do that here and have the nfsd lease break routine use it when it detects
      that there was a race between setting up the lease and it being broken.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      4d01b7f5
    • J
      locks: move freeing of leases outside of i_lock · c45198ed
      Jeff Layton 提交于
      There was only one place where we still could free a file_lock while
      holding the i_lock -- lease_modify. Add a new list_head argument to the
      lm_change operation, pass in a private list when calling it, and fix
      those callers to dispose of the list once the lock has been dropped.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      c45198ed
    • J
      locks: define a lm_setup handler for leases · 1c7dd2ff
      Jeff Layton 提交于
      ...and move the fasync setup into it for fcntl lease calls. At the same
      time, change the semantics of how the file_lock double-pointer is
      handled. Up until now, on a successful lease return you got a pointer to
      the lock on the list. This is bad, since that pointer can no longer be
      relied on as valid once the inode->i_lock has been released.
      
      Change the code to instead just zero out the pointer if the lease we
      passed in ended up being used. Then the callers can just check to see
      if it's NULL after the call and free it if it isn't.
      
      The priv argument has the same semantics. The lm_setup function can
      zero the pointer out to signal to the caller that it should not be
      freed after the function returns.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      1c7dd2ff
    • J
      locks: plumb a "priv" pointer into the setlease routines · e6f5c789
      Jeff Layton 提交于
      In later patches, we're going to add a new lock_manager_operation to
      finish setting up the lease while still holding the i_lock.  To do
      this, we'll need to pass a little bit of info in the fcntl setlease
      case (primarily an fasync structure). Plumb the extra pointer into
      there in advance of that.
      
      We declare this pointer as a void ** to make it clear that this is
      private info, and that the caller isn't required to set this unless
      the lm_setup specifically requires it.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      e6f5c789
    • J
      nfsd: don't keep a pointer to the lease in nfs4_file · 0c637be8
      Jeff Layton 提交于
      Now that we don't need to pass in an actual lease pointer to
      vfs_setlease on unlock, we can stop tracking a pointer to the lease in
      the nfs4_file.
      
      Switch all of the places that check the fi_lease to check fi_deleg_file
      instead. We always set that at the same time so it will have the same
      semantics.
      
      Cc: J. Bruce Fields <bfields@fieldses.org>
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      0c637be8
    • J
      locks: generic_delete_lease doesn't need a file_lock at all · 0efaa7e8
      Jeff Layton 提交于
      Ensure that it's OK to pass in a NULL file_lock double pointer on
      a F_UNLCK request and convert the vfs_setlease F_UNLCK callers to
      do just that.
      
      Finally, turn the BUG_ON in generic_setlease into a WARN_ON_ONCE
      with an error return. That's a problem we can handle without
      crashing the box if it occurs.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      0efaa7e8