1. 09 6月, 2016 4 次提交
  2. 08 6月, 2016 6 次提交
  3. 03 6月, 2016 20 次提交
  4. 29 5月, 2016 9 次提交
    • G
      hash_string: Fix zero-length case for !DCACHE_WORD_ACCESS · e0ab7af9
      George Spelvin 提交于
      The self-test was updated to cover zero-length strings; the function
      needs to be updated, too.
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NGeorge Spelvin <linux@sciencehorizons.net>
      Fixes: fcfd2fbf ("fs/namei.c: Add hashlen_string() function")
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e0ab7af9
    • G
      Rename other copy of hash_string to hashlen_string · f2a031b6
      George Spelvin 提交于
      The original name was simply hash_string(), but that conflicted with a
      function with that name in drivers/base/power/trace.c, and I decided
      that calling it "hashlen_" was better anyway.
      
      But you have to do it in two places.
      
      [ This caused build errors for architectures that don't define
        CONFIG_DCACHE_WORD_ACCESS   - Linus ]
      Signed-off-by: NGeorge Spelvin <linux@sciencehorizons.net>
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Fixes: fcfd2fbf ("fs/namei.c: Add hashlen_string() function")
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f2a031b6
    • M
      hpfs: implement the show_options method · 037369b8
      Mikulas Patocka 提交于
      The HPFS filesystem used generic_show_options to produce string that is
      displayed in /proc/mounts.  However, there is a problem that the options
      may disappear after remount.  If we mount the filesystem with option1
      and then remount it with option2, /proc/mounts should show both option1
      and option2, however it only shows option2 because the whole option
      string is replaced with replace_mount_options in hpfs_remount_fs.
      
      To fix this bug, implement the hpfs_show_options function that prints
      options that are currently selected.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      037369b8
    • M
      affs: fix remount failure when there are no options changed · 01d6e087
      Mikulas Patocka 提交于
      Commit c8f33d0b ("affs: kstrdup() memory handling") checks if the
      kstrdup function returns NULL due to out-of-memory condition.
      
      However, if we are remounting a filesystem with no change to
      filesystem-specific options, the parameter data is NULL.  In this case,
      kstrdup returns NULL (because it was passed NULL parameter), although no
      out of memory condition exists.  The mount syscall then fails with
      ENOMEM.
      
      This patch fixes the bug.  We fail with ENOMEM only if data is non-NULL.
      
      The patch also changes the call to replace_mount_options - if we didn't
      pass any filesystem-specific options, we don't call
      replace_mount_options (thus we don't erase existing reported options).
      
      Fixes: c8f33d0b ("affs: kstrdup() memory handling")
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org	# v4.1+
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      01d6e087
    • M
      hpfs: fix remount failure when there are no options changed · 44d51706
      Mikulas Patocka 提交于
      Commit ce657611 ("hpfs: kstrdup() out of memory handling") checks if
      the kstrdup function returns NULL due to out-of-memory condition.
      
      However, if we are remounting a filesystem with no change to
      filesystem-specific options, the parameter data is NULL.  In this case,
      kstrdup returns NULL (because it was passed NULL parameter), although no
      out of memory condition exists.  The mount syscall then fails with
      ENOMEM.
      
      This patch fixes the bug.  We fail with ENOMEM only if data is non-NULL.
      
      The patch also changes the call to replace_mount_options - if we didn't
      pass any filesystem-specific options, we don't call
      replace_mount_options (thus we don't erase existing reported options).
      
      Fixes: ce657611 ("hpfs: kstrdup() out of memory handling")
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      44d51706
    • G
      fs: fix binfmt_aout.c build error · d66492bc
      Guenter Roeck 提交于
      Various builds (such as i386:allmodconfig) fail with
      
        fs/binfmt_aout.c:133:2: error: expected identifier or '(' before 'return'
        fs/binfmt_aout.c:134:1: error: expected identifier or '(' before '}' token
      
      [ Oops. My bad, I had stupidly thought that "allmodconfig" covered this
        on x86-64 too, but it obviously doesn't.  Egg on my face.  - Linus ]
      
      Fixes: 5d22fc25 ("mm: remove more IS_ERR_VALUE abuses")
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d66492bc
    • G
      <linux/hash.h>: Add support for architecture-specific functions · 468a9428
      George Spelvin 提交于
      This is just the infrastructure; there are no users yet.
      
      This is modelled on CONFIG_ARCH_RANDOM; a CONFIG_ symbol declares
      the existence of <asm/hash.h>.
      
      That file may define its own versions of various functions, and define
      HAVE_* symbols (no CONFIG_ prefix!) to suppress the generic ones.
      
      Included is a self-test (in lib/test_hash.c) that verifies the basics.
      It is NOT in general required that the arch-specific functions compute
      the same thing as the generic, but if a HAVE_* symbol is defined with
      the value 1, then equality is tested.
      Signed-off-by: NGeorge Spelvin <linux@sciencehorizons.net>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greg Ungerer <gerg@linux-m68k.org>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Cc: Philippe De Muyter <phdm@macq.eu>
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: Alistair Francis <alistai@xilinx.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: uclinux-h8-devel@lists.sourceforge.jp
      468a9428
    • G
      fs/namei.c: Improve dcache hash function · 2a18da7a
      George Spelvin 提交于
      Patch 0fed3ac8 improved the hash mixing, but the function is slower
      than necessary; there's a 7-instruction dependency chain (10 on x86)
      each loop iteration.
      
      Word-at-a-time access is a very tight loop (which is good, because
      link_path_walk() is one of the hottest code paths in the entire kernel),
      and the hash mixing function must not have a longer latency to avoid
      slowing it down.
      
      There do not appear to be any published fast hash functions that:
      1) Operate on the input a word at a time, and
      2) Don't need to know the length of the input beforehand, and
      3) Have a single iterated mixing function, not needing conditional
         branches or unrolling to distinguish different loop iterations.
      
      One of the algorithms which comes closest is Yann Collet's xxHash, but
      that's two dependent multiplies per word, which is too much.
      
      The key insights in this design are:
      
      1) Barring expensive ops like multiplies, to diffuse one input bit
         across 64 bits of hash state takes at least log2(64) = 6 sequentially
         dependent instructions.  That is more cycles than we'd like.
      2) An operation like "hash ^= hash << 13" requires a second temporary
         register anyway, and on a 2-operand machine like x86, it's three
         instructions.
      3) A better use of a second register is to hold a two-word hash state.
         With careful design, no temporaries are needed at all, so it doesn't
         increase register pressure.  And this gets rid of register copying
         on 2-operand machines, so the code is smaller and faster.
      4) Using two words of state weakens the requirement for one-round mixing;
         we now have two rounds of mixing before cancellation is possible.
      5) A two-word hash state also allows operations on both halves to be
         done in parallel, so on a superscalar processor we get more mixing
         in fewer cycles.
      
      I ended up using a mixing function inspired by the ChaCha and Speck
      round functions.  It is 6 simple instructions and 3 cycles per iteration
      (assuming multiply by 9 can be done by an "lea" instruction):
      
      		x ^= *input++;
      	y ^= x;	x = ROL(x, K1);
      	x += y;	y = ROL(y, K2);
      	y *= 9;
      
      Not only is this reversible, two consecutive rounds are reversible:
      if you are given the initial and final states, but not the intermediate
      state, it is possible to compute both input words.  This means that at
      least 3 words of input are required to create a collision.
      
      (It also has the property, used by hash_name() to avoid a branch, that
      it hashes all-zero to all-zero.)
      
      The rotate constants K1 and K2 were found by experiment.  The search took
      a sample of random initial states (I used 1023) and considered the effect
      of flipping each of the 64 input bits on each of the 128 output bits two
      rounds later.  Each of the 8192 pairs can be considered a biased coin, and
      adding up the Shannon entropy of all of them produces a score.
      
      The best-scoring shifts also did well in other tests (flipping bits in y,
      trying 3 or 4 rounds of mixing, flipping all 64*63/2 pairs of input bits),
      so the choice was made with the additional constraint that the sum of the
      shifts is odd and not too close to the word size.
      
      The final state is then folded into a 32-bit hash value by a less carefully
      optimized multiply-based scheme.  This also has to be fast, as pathname
      components tend to be short (the most common case is one iteration!), but
      there's some room for latency, as there is a fair bit of intervening logic
      before the hash value is used for anything.
      
      (Performance verified with "bonnie++ -s 0 -n 1536:-2" on tmpfs.  I need
      a better benchmark; the numbers seem to show a slight dip in performance
      between 4.6.0 and this patch, but they're too noisy to quote.)
      
      Special thanks to Bruce fields for diligent testing which uncovered a
      nasty fencepost error in an earlier version of this patch.
      
      [checkpatch.pl formatting complaints noted and respectfully disagreed with.]
      Signed-off-by: NGeorge Spelvin <linux@sciencehorizons.net>
      Tested-by: NJ. Bruce Fields <bfields@redhat.com>
      2a18da7a
    • G
      fs/namei.c: Add hashlen_string() function · fcfd2fbf
      George Spelvin 提交于
      We'd like to make more use of the highly-optimized dcache hash functions
      throughout the kernel, rather than have every subsystem create its own,
      and a function that hashes basic null-terminated strings is required
      for that.
      
      (The name is to emphasize that it returns both hash and length.)
      
      It's actually useful in the dcache itself, specifically d_alloc_name().
      Other uses in the next patch.
      
      full_name_hash() is also tweaked to make it more generally useful:
      1) Take a "char *" rather than "unsigned char *" argument, to
         be consistent with hash_name().
      2) Handle zero-length inputs.  If we want more callers, we don't want
         to make them worry about corner cases.
      Signed-off-by: NGeorge Spelvin <linux@sciencehorizons.net>
      fcfd2fbf
  5. 28 5月, 2016 1 次提交
    • L
      nfs: fix anonymous member initializer build failure with older compilers · e0714ec4
      Linus Torvalds 提交于
      Older versions of gcc don't understand named initializers inside a
      anonymous structure or union member.  It can be worked around by adding
      the bracin gin the initializer for the anonymous member.
      
      Without this, gcc 4.4.4 will fail the build with
      
          CC      fs/nfs/nfs4state.o
        fs/nfs/nfs4state.c:69: error: unknown field ‘data’ specified in initializer
        fs/nfs/nfs4state.c:69: warning: missing braces around initializer
        fs/nfs/nfs4state.c:69: warning: (near initialization for ‘zero_stateid.<anonymous>.data’)
        make[2]: *** [fs/nfs/nfs4state.o] Error 1
      
      introduced in commit 93b717fd ("NFSv4: Label stateids with the type")
      Reported-and-tested-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Anna Schumaker <Anna.Schumaker@netapp.com>
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e0714ec4