This project is mirrored from Pull mirroring updated .
  1. 28 May, 2016 1 commit
    • George Spelvin's avatar
      Change hash_64() return value to 32 bits · 92d56774
      George Spelvin authored
      That's all that's ever asked for, and it makes the return
      type of hash_long() consistent.
      It also allows (upcoming patch) an optimized implementation
      of hash_64 on 32-bit machines.
      I tried adding a BUILD_BUG_ON to ensure the number of bits requested
      was never more than 32 (most callers use a compile-time constant), but
      adding <linux/bug.h> to <linux/hash.h> breaks the tools/perf compiler
      unless tools/perf/MANIFEST is updated, and understanding that code base
      well enough to update it is too much trouble.  I did the rest of an
      allyesconfig build with such a check, and nothing tripped.
      Signed-off-by: default avatarGeorge Spelvin <>
  2. 02 May, 2016 1 commit
    • Linus Torvalds's avatar
      Minimal fix-up of bad hashing behavior of hash_64() · 689de1d6
      Linus Torvalds authored
      This is a fairly minimal fixup to the horribly bad behavior of hash_64()
      with certain input patterns.
      In particular, because the multiplicative value used for the 64-bit hash
      was intentionally bit-sparse (so that the multiply could be done with
      shifts and adds on architectures without hardware multipliers), some
      bits did not get spread out very much.  In particular, certain fairly
      common bit ranges in the input (roughly bits 12-20: commonly with the
      most information in them when you hash things like byte offsets in files
      or memory that have block factors that mean that the low bits are often
      zero) would not necessarily show up much in the result.
      There's a bigger patch-series brewing to fix up things more completely,
      but this is the fairly minimal fix for the 64-bit hashing problem.  It
      simply picks a much better constant multiplier, spreading the bits out a
      lot better.
      NOTE! For 32-bit architectures, the bad old hash_64() remains the same
      for now, since 64-bit multiplies are expensive.  The bigger hashing
      cleanup will replace the 32-bit case with something better.
      The new constants were picked by George Spelvin who wrote that bigger
      cleanup series.  I just picked out the constants and part of the comment
      from that series.
      Cc: George Spelvin <>
      Cc: Thomas Gleixner <>
      Signed-off-by: default avatarLinus Torvalds <>
  3. 10 Dec, 2014 1 commit
  4. 14 Nov, 2014 1 commit
    • Jay Vosburgh's avatar
      Revert "fast_hash: avoid indirect function calls" · a77f9c5d
      Jay Vosburgh authored
      This reverts commit e5a2c899.
      	Commit e5a2c899
       introduced an alternative_call, arch_fast_hash2,
      that selects between __jhash2 and __intel_crc4_2_hash based on the
      	Unfortunately, the alternative_call system does not appear to be
      suitable for use with C functions, as register usage is not handled
      properly for the called functions.  The __jhash2 function in particular
      clobbers registers that are not preserved when called via
      alternative_call, resulting in a panic for direct callers of
      arch_fast_hash2 on older CPUs lacking sse4_2.  It is possible that
      __intel_crc4_2_hash works merely by chance because it uses fewer
      	This commit was suggested as the source of the problem by Jesse
      Gross <>.
      Signed-off-by: default avatarJay Vosburgh <>
      Signed-off-by: default avatarDavid S. Miller <>
  5. 06 Nov, 2014 1 commit
  6. 13 Sep, 2014 1 commit
    • Linus Torvalds's avatar
      Make hash_64() use a 64-bit multiply when appropriate · 23d0db76
      Linus Torvalds authored
      The hash_64() function historically does the multiply by the
      GOLDEN_RATIO_PRIME_64 number with explicit shifts and adds, because
      unlike the 32-bit case, gcc seems unable to turn the constant multiply
      into the more appropriate shift and adds when required.
      However, that means that we generate those shifts and adds even when the
      architecture has a fast multiplier, and could just do it better in
      Use the now-cleaned-up CONFIG_ARCH_HAS_FAST_MULTIPLIER (together with
      "is it a 64-bit architecture") to decide whether to use an integer
      multiply or the explicit sequence of shift/add instructions.
      Signed-off-by: default avatarLinus Torvalds <>
  7. 17 Dec, 2013 1 commit
    • Francesco Fusco's avatar
      lib: introduce arch optimized hash library · 71ae8aac
      Francesco Fusco authored
      We introduce a new hashing library that is meant to be used in
      the contexts where speed is more important than uniformity of the
      hashed values. The hash library leverages architecture specific
      implementation to achieve high performance and fall backs to
      jhash() for the generic case.
      On Intel-based x86 architectures, the library can exploit the crc32l
      instruction, part of the Intel SSE4.2 instruction set, if the
      instruction is supported by the processor. This implementation
      is twice as fast as the jhash() implementation on an i7 processor.
      Additional architectures, such as Arm64 provide instructions for
      accelerating the computation of CRC, so they could be added as well
      in follow-up work.
      Signed-off-by: default avatarFrancesco Fusco <>
      Signed-off-by: default avatarDaniel Borkmann <>
      Signed-off-by: default avatarThomas Graf <>
      Signed-off-by: default avatarDavid S. Miller <>
  8. 18 Mar, 2013 1 commit
  9. 06 Dec, 2012 1 commit
  10. 09 Aug, 2012 1 commit
  11. 17 Aug, 2011 1 commit
  12. 06 Feb, 2008 1 commit
  13. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!