1. 20 Nov, 2018 1 commit
    • Eric Biggers's avatar
      crypto: chacha20-generic - refactor to allow varying number of rounds · 1ca1b917
      Eric Biggers authored
      In preparation for adding XChaCha12 support, rename/refactor
      chacha20-generic to support different numbers of rounds.  The
      justification for needing XChaCha12 support is explained in more detail
      in the patch "crypto: chacha - add XChaCha12 support".
      
      The only difference between ChaCha{8,12,20} are the number of rounds
      itself; all other parts of the algorithm are the same.  Therefore,
      remove the "20" from all definitions, structures, functions, files, etc.
      that will be shared by all ChaCha versions.
      
      Also make ->setkey() store the round count in the chacha_ctx (previously
      chacha20_ctx).  The generic code then passes the round count through to
      chacha_block().  There will be a ->setkey() function for each explicitly
      allowed round count; the encrypt/decrypt functions will be the same.  I
      decided not to do it the opposite way (same ->setkey() function for all
      round counts, with different encrypt/decrypt functions) because that
      would have required more boilerplate code in architecture-specific
      implementations of ChaCha and XChaCha.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1ca1b917
  2. 15 Nov, 2018 1 commit
  3. 31 Oct, 2018 1 commit
  4. 23 Oct, 2018 1 commit
    • Zong Li's avatar
      lib: Add umoddi3 and udivmoddi4 of GCC library routines · 6315730e
      Zong Li authored
      Add umoddi3 and udivmoddi4 support for 32-bit.
      
      The RV32 need the umoddi3 to do modulo when the operands are long long
      type, like other libraries implementation such as ucmpdi2, lshrdi3 and
      so on.
      
      I encounter the undefined reference 'umoddi3' when I use the in
      house dma driver, although it is in house driver, but I think that
      umoddi3 is a common function for RV32.
      
      The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other
      functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and
      udivmoddi4 for flexible extension in the future.
      Signed-off-by: default avatarZong Li <zong@andestech.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      6315730e
  5. 21 Oct, 2018 2 commits
  6. 16 Oct, 2018 1 commit
    • Alexander Shishkin's avatar
      lib: Fix ia64 bootloader linkage · 93048c09
      Alexander Shishkin authored
      kbuild robot reports that since commit ce76d938 ("lib: Add memcat_p():
      paste 2 pointer arrays together") the ia64/hp/sim/boot fails to link:
      
      > LD      arch/ia64/hp/sim/boot/bootloader
      > lib/string.o: In function `__memcat_p':
      > string.c:(.text+0x1f22): undefined reference to `__kmalloc'
      > string.c:(.text+0x1ff2): undefined reference to `__kmalloc'
      > make[1]: *** [arch/ia64/hp/sim/boot/Makefile:37: arch/ia64/hp/sim/boot/bootloader] Error 1
      
      The reason is, the above commit, via __memcat_p(), adds a call to
      __kmalloc to string.o, which happens to be used in the bootloader, but
      there's no kmalloc or slab or anything.
      
      Since the linker would only pull in objects that contain referenced
      symbols, moving __memcat_p() to a different compilation unit solves the
      problem.
      
      Fixes: ce76d938 ("lib: Add memcat_p(): paste 2 pointer arrays together")
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93048c09
  7. 12 Oct, 2018 1 commit
    • Arnd Bergmann's avatar
      lib/bch: fix possible stack overrun · f0fe77f6
      Arnd Bergmann authored
      The previous patch introduced very large kernel stack usage and a Makefile
      change to hide the warning about it.
      
      From what I can tell, a number of things went wrong here:
      
      - The BCH_MAX_T constant was set to the maximum value for 'n',
        not the maximum for 't', which is much smaller.
      
      - The stack usage is actually larger than the entire kernel stack
        on some architectures that can use 4KB stacks (m68k, sh, c6x), which
        leads to an immediate overrun.
      
      - The justification in the patch description claimed that nothing
        changed, however that is not the case even without the two points above:
        the configuration is machine specific, and most boards  never use the
        maximum BCH_ECC_WORDS() length but instead have something much smaller.
        That maximum would only apply to machines that use both the maximum
        block size and the maximum ECC strength.
      
      The largest value for 't' that I could find is '32', which in turn leads
      to a 60 byte array instead of 2048 bytes. Making it '64' for future
      extension seems also worthwhile, with 120 bytes for the array. Anything
      larger won't fit into the OOB area on NAND flash.
      
      With that changed, the warning can be enabled again.
      
      Only linux-4.19+ contains the breakage, so this is only needed
      as a stable backport if it does not make it into the release.
      
      Fixes: 02361bc7 ("lib/bch: Remove VLA usage")
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      f0fe77f6
  8. 11 Oct, 2018 2 commits
  9. 22 Aug, 2018 2 commits
    • Coly Li's avatar
      lib: add crc64 calculation routines · feba04fd
      Coly Li authored
      Patch series "add crc64 calculation as kernel library", v5.
      
      This patchset adds basic implementation of crc64 calculation as a Linux
      kernel library.  Since bcache already does crc64 by itself, this patchset
      also modifies bcache code to use the new crc64 library routine.
      
      Currently bcache is the only user of crc64 calculation, another potential
      user is bcachefs which is on the way to be in mainline kernel.  Therefore
      it makes sense to make crc64 calculation to be a public library.
      
      bcache uses crc64 as storage checksum, if a change of crc lib routines
      results an inconsistent result, the unmatched checksum may make bcache
      'think' the on-disk is corrupted, such a change should be avoided or
      detected as early as possible.  Therefore a patch is being prepared which
      adds a crc test framework, to check consistency of different calculations.
      
      This patch (of 2):
      
      Add the re-write crc64 calculation routines for Linux kernel.  The CRC64
      polynomical arithmetic follows ECMA-182 specification, inspired by CRC
      paper of Dr.  Ross N.  Williams (see
      http://www.ross.net/crc/download/crc_v3.txt) and other public domain
      implementations.
      
      All the changes work in this way,
      - When Linux kernel is built, host program lib/gen_crc64table.c will be
        compiled to lib/gen_crc64table and executed.
      - The output of gen_crc64table execution is an array called as lookup
        table (a.k.a POLY 0x42f0e1eba9ea369) which contain 256 64-bit long
        numbers, this table is dumped into header file lib/crc64table.h.
      - Then the header file is included by lib/crc64.c for normal 64bit crc
        calculation.
      - Function declaration of the crc64 calculation routines is placed in
        include/linux/crc64.h
      
      Currently bcache is the only user of crc64_be(), another potential user is
      bcachefs which is on the way to be in mainline kernel.  Therefore it makes
      sense to move crc64 calculation into lib/crc64.c as public code.
      
      [colyli@suse.de: fix review comments from v4]
        Link: http://lkml.kernel.org/r/20180726053352.2781-2-colyli@suse.de
      Link: http://lkml.kernel.org/r/20180718165545.1622-2-colyli@suse.deSigned-off-by: default avatarColy Li <colyli@suse.de>
      Co-developed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Michael Lyle <mlyle@lyle.org>
      Cc: Kent Overstreet <kent.overstreet@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Eric Biggers <ebiggers3@gmail.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Noah Massey <noah.massey@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      feba04fd
    • Matthew Wilcox's avatar
      ida: Start new test_ida module · 8ab8ba38
      Matthew Wilcox authored
      Start transitioning the IDA tests into kernel space.  Framework heavily
      cribbed from test_xarray.c.
      Signed-off-by: default avatarMatthew Wilcox <willy@infradead.org>
      8ab8ba38
  10. 27 Jun, 2018 1 commit
  11. 21 Jun, 2018 1 commit
    • Kees Cook's avatar
      lib/bch: Remove VLA usage · 02361bc7
      Kees Cook authored
      In the quest to remove all stack VLA usage from the kernel[1], this
      allocates a fixed size stack array to cover the range needed for
      bch. This was done instead of a preallocation on the SLAB due to
      performance reasons, shown by Ivan Djelic:
      
       little-endian, type sizes: int=4 long=8 longlong=8
       cpu: Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz
       calibration: iter=4.9143µs niter=2034 nsamples=200 m=13 t=4
      
         Buffer allocation |  Encoding throughput (Mbit/s)
       ---------------------------------------------------
        on-stack, VLA      |   3988
        on-stack, fixed    |   4494
        kmalloc            |   1967
      
      So this change actually improves performance too, it seems.
      
      The resulting stack allocation can get rather large; without
      CONFIG_BCH_CONST_PARAMS, it will allocate 4096 bytes, which
      trips the stack size checking:
      
      lib/bch.c: In function ‘encode_bch’:
      lib/bch.c:261:1: warning: the frame size of 4432 bytes is larger than 2048 bytes [-Wframe-larger-than=]
      
      Even the default case for "allmodconfig" (with CONFIG_BCH_CONST_M=14 and
      CONFIG_BCH_CONST_T=4) would have started throwing a warning:
      
      lib/bch.c: In function ‘encode_bch’:
      lib/bch.c:261:1: warning: the frame size of 2288 bytes is larger than 2048 bytes [-Wframe-larger-than=]
      
      But this is how large it's always been; it was just hidden from
      the checker because it was a VLA. So the Makefile has been adjusted to
      silence this warning for anything smaller than 4500 bytes, which should
      provide room for normal cases, but still low enough to catch any future
      pathological situations.
      
      [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.comSigned-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarIvan Djelic <ivan.djelic@parrot.com>
      Tested-by: default avatarIvan Djelic <ivan.djelic@parrot.com>
      Acked-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      02361bc7
  12. 20 Jun, 2018 1 commit
  13. 14 Jun, 2018 2 commits
  14. 12 Jun, 2018 1 commit
    • Sebastian Andrzej Siewior's avatar
      alpha: Remove custom dec_and_lock() implementation · f2ae6794
      Sebastian Andrzej Siewior authored
      Alpha provides a custom implementation of dec_and_lock(). The functions
      is split into two parts:
      - atomic_add_unless() + return 0 (fast path in assembly)
      - remaining part including locking (slow path in C)
      
      Comparing the result of the alpha implementation with the generic
      implementation compiled by gcc it looks like the fast path is optimized
      by avoiding a stack frame (and reloading the GP), register store and all
      this. This is only done in the slowpath.
      After marking the slowpath (atomic_dec_and_lock_1()) as "noinline" and
      doing the slowpath in C (the atomic_add_unless(atomic, -1, 1) part) I
      noticed differences in the resulting assembly:
      - the GP is still reloaded
      - atomic_add_unless() adds more memory barriers compared to the custom
        assembly
      - the custom assembly here does "load, sub, beq" while
        atomic_add_unless() does "load, cmpeq, add, bne". This is okay because
        it compares against zero after subtraction while the generic code
        compares against 1 before.
      
      I'm not sure if avoiding the stack frame (and GP reloading) brings a lot
      in terms of performance. Regarding the different barriers, Peter
      Zijlstra says:
      
      |refcount decrement needs to be a RELEASE operation, such that all the
      |load/stores to the object happen before we decrement the refcount.
      |
      |Otherwise things like:
      |
      |        obj->foo = 5;
      |        refcnt_dec(&obj->ref);
      |
      |can be re-ordered, which then allows fun scenarios like:
      |
      |        CPU0                            CPU1
      |
      |        refcnt_dec(&obj->ref);
      |                                        if (dec_and_test(&obj->ref))
      |                                                free(obj);
      |        obj->foo = 5; // oops UaF
      |
      |
      |This means (for alpha) that there should be a memory barrier _before_
      |the decrement, however the dec_and_lock asm thing only has one _after_,
      |which, per the above, is too late.
      |
      |The generic version using add_unless will result in memory barrier
      |before and after (because that is the rule for atomic ops with a return
      |value) which is strictly too many barriers for the refcount story, but
      |who knows what other ordering requirements code has.
      
      Remove the custom alpha implementation of dec_and_lock() and if it is an
      issue (performance wise) then the fast path could still be inlined.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: linux-alpha@vger.kernel.org
      Link: https://lkml.kernel.org/r/20180606115918.GG12198@hirez.programming.kicks-ass.net
      Link: https://lkml.kernel.org/r20180612161621.22645-2-bigeasy@linutronix.de
      f2ae6794
  15. 05 Jun, 2018 1 commit
  16. 19 May, 2018 1 commit
  17. 09 May, 2018 1 commit
  18. 23 Apr, 2018 1 commit
  19. 11 Apr, 2018 2 commits
  20. 21 Mar, 2018 1 commit
  21. 15 Mar, 2018 1 commit
  22. 07 Feb, 2018 1 commit
  23. 15 Jan, 2018 1 commit
  24. 13 Jan, 2018 1 commit
    • Masami Hiramatsu's avatar
      error-injection: Separate error-injection from kprobe · 540adea3
      Masami Hiramatsu authored
      Since error-injection framework is not limited to be used
      by kprobes, nor bpf. Other kernel subsystems can use it
      freely for checking safeness of error-injection, e.g.
      livepatch, ftrace etc.
      So this separate error-injection framework from kprobes.
      
      Some differences has been made:
      
      - "kprobe" word is removed from any APIs/structures.
      - BPF_ALLOW_ERROR_INJECTION() is renamed to
        ALLOW_ERROR_INJECTION() since it is not limited for BPF too.
      - CONFIG_FUNCTION_ERROR_INJECTION is the config item of this
        feature. It is automatically enabled if the arch supports
        error injection feature for kprobe or ftrace etc.
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      540adea3
  25. 11 Dec, 2017 1 commit
  26. 18 Nov, 2017 2 commits
  27. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  28. 25 Sep, 2017 1 commit
  29. 09 Sep, 2017 1 commit
  30. 15 Aug, 2017 2 commits
    • Nick Terrell's avatar
      lib: Add zstd modules · 73f3d1b4
      Nick Terrell authored
      Add zstd compression and decompression kernel modules.
      zstd offers a wide varity of compression speed and quality trade-offs.
      It can compress at speeds approaching lz4, and quality approaching lzma.
      zstd decompressions at speeds more than twice as fast as zlib, and
      decompression speed remains roughly the same across all compression levels.
      
      The code was ported from the upstream zstd source repository. The
      `linux/zstd.h` header was modified to match linux kernel style.
      The cross-platform and allocation code was stripped out. Instead zstd
      requires the caller to pass a preallocated workspace. The source files
      were clang-formatted [1] to match the Linux Kernel style as much as
      possible. Otherwise, the code was unmodified. We would like to avoid
      as much further manual modification to the source code as possible, so it
      will be easier to keep the kernel zstd up to date.
      
      I benchmarked zstd compression as a special character device. I ran zstd
      and zlib compression at several levels, as well as performing no
      compression, which measure the time spent copying the data to kernel space.
      Data is passed to the compresser 4096 B at a time. The benchmark file is
      located in the upstream zstd source repository under
      `contrib/linux-kernel/zstd_compress_test.c` [2].
      
      I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
      The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
      16 GB of RAM, and a SSD. I benchmarked using `silesia.tar` [3], which is
      211,988,480 B large. Run the following commands for the benchmark:
      
          sudo modprobe zstd_compress_test
          sudo mknod zstd_compress_test c 245 0
          sudo cp silesia.tar zstd_compress_test
      
      The time is reported by the time of the userland `cp`.
      The MB/s is computed with
      
          1,536,217,008 B / time(buffer size, hash)
      
      which includes the time to copy from userland.
      The Adjusted MB/s is computed with
      
          1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
      
      The memory reported is the amount of memory the compressor requests.
      
      | Method   | Size (B) | Time (s) | Ratio | MB/s    | Adj MB/s | Mem (MB) |
      |----------|----------|----------|-------|---------|----------|----------|
      | none     | 11988480 |    0.100 |     1 | 2119.88 |        - |        - |
      | zstd -1  | 73645762 |    1.044 | 2.878 |  203.05 |   224.56 |     1.23 |
      | zstd -3  | 66988878 |    1.761 | 3.165 |  120.38 |   127.63 |     2.47 |
      | zstd -5  | 65001259 |    2.563 | 3.261 |   82.71 |    86.07 |     2.86 |
      | zstd -10 | 60165346 |   13.242 | 3.523 |   16.01 |    16.13 |    13.22 |
      | zstd -15 | 58009756 |   47.601 | 3.654 |    4.45 |     4.46 |    21.61 |
      | zstd -19 | 54014593 |  102.835 | 3.925 |    2.06 |     2.06 |    60.15 |
      | zlib -1  | 77260026 |    2.895 | 2.744 |   73.23 |    75.85 |     0.27 |
      | zlib -3  | 72972206 |    4.116 | 2.905 |   51.50 |    52.79 |     0.27 |
      | zlib -6  | 68190360 |    9.633 | 3.109 |   22.01 |    22.24 |     0.27 |
      | zlib -9  | 67613382 |   22.554 | 3.135 |    9.40 |     9.44 |     0.27 |
      
      I benchmarked zstd decompression using the same method on the same machine.
      The benchmark file is located in the upstream zstd repo under
      `contrib/linux-kernel/zstd_decompress_test.c` [4]. The memory reported is
      the amount of memory required to decompress data compressed with the given
      compression level. If you know the maximum size of your input, you can
      reduce the memory usage of decompression irrespective of the compression
      level.
      
      | Method   | Time (s) | MB/s    | Adjusted MB/s | Memory (MB) |
      |----------|----------|---------|---------------|-------------|
      | none     |    0.025 | 8479.54 |             - |           - |
      | zstd -1  |    0.358 |  592.15 |        636.60 |        0.84 |
      | zstd -3  |    0.396 |  535.32 |        571.40 |        1.46 |
      | zstd -5  |    0.396 |  535.32 |        571.40 |        1.46 |
      | zstd -10 |    0.374 |  566.81 |        607.42 |        2.51 |
      | zstd -15 |    0.379 |  559.34 |        598.84 |        4.61 |
      | zstd -19 |    0.412 |  514.54 |        547.77 |        8.80 |
      | zlib -1  |    0.940 |  225.52 |        231.68 |        0.04 |
      | zlib -3  |    0.883 |  240.08 |        247.07 |        0.04 |
      | zlib -6  |    0.844 |  251.17 |        258.84 |        0.04 |
      | zlib -9  |    0.837 |  253.27 |        287.64 |        0.04 |
      
      Tested in userland using the test-suite in the zstd repo under
      `contrib/linux-kernel/test/UserlandTest.cpp` [5] by mocking the kernel
      functions. Fuzz tested using libfuzzer [6] with the fuzz harnesses under
      `contrib/linux-kernel/test/{RoundTripCrash.c,DecompressCrash.c}` [7] [8]
      with ASAN, UBSAN, and MSAN. Additionaly, it was tested while testing the
      BtrFS and SquashFS patches coming next.
      
      [1] https://clang.llvm.org/docs/ClangFormat.html
      [2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_compress_test.c
      [3] http://sun.aei.polsl.pl/~sdeor/index.php?page=silesia
      [4] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/zstd_decompress_test.c
      [5] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/UserlandTest.cpp
      [6] http://llvm.org/docs/LibFuzzer.html
      [7] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/RoundTripCrash.c
      [8] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/DecompressCrash.c
      
      zstd source repository: https://github.com/facebook/zstdSigned-off-by: default avatarNick Terrell <terrelln@fb.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      73f3d1b4
    • Nick Terrell's avatar
      lib: Add xxhash module · 5d240522
      Nick Terrell authored
      Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an
      extremely fast non-cryptographic hash algorithm for checksumming.
      The zstd compression and decompression modules added in the next patch
      require xxhash. I extracted it out from zstd since it is useful on its
      own. I copied the code from the upstream XXHash source repository and
      translated it into kernel style. I ran benchmarks and tests in the kernel
      and tests in userland.
      
      I benchmarked xxhash as a special character device. I ran in four modes,
      no-op, xxh32, xxh64, and crc32. The no-op mode simply copies the data to
      kernel space and ignores it. The xxh32, xxh64, and crc32 modes compute
      hashes on the copied data. I also ran it with four different buffer sizes.
      The benchmark file is located in the upstream zstd source repository under
      `contrib/linux-kernel/xxhash_test.c` [1].
      
      I ran the benchmarks on a Ubuntu 14.04 VM with 2 cores and 4 GiB of RAM.
      The VM is running on a MacBook Pro with a 3.1 GHz Intel Core i7 processor,
      16 GB of RAM, and a SSD. I benchmarked using the file `filesystem.squashfs`
      from `ubuntu-16.10-desktop-amd64.iso`, which is 1,536,217,088 B large.
      Run the following commands for the benchmark:
      
          modprobe xxhash_test
          mknod xxhash_test c 245 0
          time cp filesystem.squashfs xxhash_test
      
      The time is reported by the time of the userland `cp`.
      The GB/s is computed with
      
          1,536,217,008 B / time(buffer size, hash)
      
      which includes the time to copy from userland.
      The Normalized GB/s is computed with
      
          1,536,217,088 B / (time(buffer size, hash) - time(buffer size, none)).
      
      | Buffer Size (B) | Hash  | Time (s) | GB/s | Adjusted GB/s |
      |-----------------|-------|----------|------|---------------|
      |            1024 | none  |    0.408 | 3.77 |             - |
      |            1024 | xxh32 |    0.649 | 2.37 |          6.37 |
      |            1024 | xxh64 |    0.542 | 2.83 |         11.46 |
      |            1024 | crc32 |    1.290 | 1.19 |          1.74 |
      |            4096 | none  |    0.380 | 4.04 |             - |
      |            4096 | xxh32 |    0.645 | 2.38 |          5.79 |
      |            4096 | xxh64 |    0.500 | 3.07 |         12.80 |
      |            4096 | crc32 |    1.168 | 1.32 |          1.95 |
      |            8192 | none  |    0.351 | 4.38 |             - |
      |            8192 | xxh32 |    0.614 | 2.50 |          5.84 |
      |            8192 | xxh64 |    0.464 | 3.31 |         13.60 |
      |            8192 | crc32 |    1.163 | 1.32 |          1.89 |
      |           16384 | none  |    0.346 | 4.43 |             - |
      |           16384 | xxh32 |    0.590 | 2.60 |          6.30 |
      |           16384 | xxh64 |    0.466 | 3.30 |         12.80 |
      |           16384 | crc32 |    1.183 | 1.30 |          1.84 |
      
      Tested in userland using the test-suite in the zstd repo under
      `contrib/linux-kernel/test/XXHashUserlandTest.cpp` [2] by mocking the
      kernel functions. A line in each branch of every function in `xxhash.c`
      was commented out to ensure that the test-suite fails. Additionally
      tested while testing zstd and with SMHasher [3].
      
      [1] https://phabricator.intern.facebook.com/P57526246
      [2] https://github.com/facebook/zstd/blob/dev/contrib/linux-kernel/test/XXHashUserlandTest.cpp
      [3] https://github.com/aappleby/smhasher
      
      zstd source repository: https://github.com/facebook/zstd
      XXHash source repository: https://github.com/cyan4973/xxhashSigned-off-by: default avatarNick Terrell <terrelln@fb.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      5d240522
  31. 14 Jul, 2017 1 commit
    • Luis R. Rodriguez's avatar
      kmod: add test driver to stress test the module loader · d9c6a72d
      Luis R. Rodriguez authored
      This adds a new stress test driver for kmod: the kernel module loader.
      The new stress test driver, test_kmod, is only enabled as a module right
      now.  It should be possible to load this as built-in and load tests
      early (refer to the force_init_test module parameter), however since a
      lot of test can get a system out of memory fast we leave this disabled
      for now.
      
      Using a system with 1024 MiB of RAM can *easily* get your kernel OOM
      fast with this test driver.
      
      The test_kmod driver exposes API knobs for us to fine tune simple
      request_module() and get_fs_type() calls.  Since these API calls only
      allow each one parameter a test driver for these is rather simple.
      Other factors that can help out test driver though are the number of
      calls we issue and knowing current limitations of each.  This exposes
      configuration as much as possible through userspace to be able to build
      tests directly from userspace.
      
      Since it allows multiple misc devices its will eventually (once we add a
      knob to let us create new devices at will) also be possible to perform
      more tests in parallel, provided you have enough memory.
      
      We only enable tests we know work as of right now.
      
      Demo screenshots:
      
       # tools/testing/selftests/kmod/kmod.sh
      kmod_test_0001_driver: OK! - loading kmod test
      kmod_test_0001_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected MODULE_NOT_FOUND
      kmod_test_0001_fs: OK! - loading kmod test
      kmod_test_0001_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
      kmod_test_0002_driver: OK! - loading kmod test
      kmod_test_0002_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected MODULE_NOT_FOUND
      kmod_test_0002_fs: OK! - loading kmod test
      kmod_test_0002_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
      kmod_test_0003: OK! - loading kmod test
      kmod_test_0003: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0004: OK! - loading kmod test
      kmod_test_0004: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0005: OK! - loading kmod test
      kmod_test_0005: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0006: OK! - loading kmod test
      kmod_test_0006: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0005: OK! - loading kmod test
      kmod_test_0005: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0006: OK! - loading kmod test
      kmod_test_0006: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      XXX: add test restult for 0007
      Test completed
      
      You can also request for specific tests:
      
       # tools/testing/selftests/kmod/kmod.sh -t 0001
      kmod_test_0001_driver: OK! - loading kmod test
      kmod_test_0001_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected MODULE_NOT_FOUND
      kmod_test_0001_fs: OK! - loading kmod test
      kmod_test_0001_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
      Test completed
      
      Lastly, the current available number of tests:
      
       # tools/testing/selftests/kmod/kmod.sh --help
      Usage: tools/testing/selftests/kmod/kmod.sh [ -t <4-number-digit> ]
      Valid tests: 0001-0009
      
      0001 - Simple test - 1 thread  for empty string
      0002 - Simple test - 1 thread  for modules/filesystems that do not exist
      0003 - Simple test - 1 thread  for get_fs_type() only
      0004 - Simple test - 2 threads for get_fs_type() only
      0005 - multithreaded tests with default setup - request_module() only
      0006 - multithreaded tests with default setup - get_fs_type() only
      0007 - multithreaded tests with default setup test request_module() and get_fs_type()
      0008 - multithreaded - push kmod_concurrent over max_modprobes for request_module()
      0009 - multithreaded - push kmod_concurrent over max_modprobes for get_fs_type()
      
      The following test cases currently fail, as such they are not currently
      enabled by default:
      
       # tools/testing/selftests/kmod/kmod.sh -t 0008
       # tools/testing/selftests/kmod/kmod.sh -t 0009
      
      To be sure to run them as intended please unload both of the modules:
      
        o test_module
        o xfs
      
      And ensure they are not loaded on your system prior to testing them.  If
      you use these paritions for your rootfs you can change the default test
      driver used for get_fs_type() by exporting it into your environment.  For
      example of other test defaults you can override refer to kmod.sh
      allow_user_defaults().
      
      Behind the scenes this is how we fine tune at a test case prior to
      hitting a trigger to run it:
      
      cat /sys/devices/virtual/misc/test_kmod0/config
      echo -n "2" > /sys/devices/virtual/misc/test_kmod0/config_test_case
      echo -n "ext4" > /sys/devices/virtual/misc/test_kmod0/config_test_fs
      echo -n "80" > /sys/devices/virtual/misc/test_kmod0/config_num_threads
      cat /sys/devices/virtual/misc/test_kmod0/config
      echo -n "1" > /sys/devices/virtual/misc/test_kmod0/config_num_threads
      
      Finally to trigger:
      
      echo -n "1" > /sys/devices/virtual/misc/test_kmod0/trigger_config
      
      The kmod.sh script uses the above constructs to build different test cases.
      
      A bit of interpretation of the current failures follows, first two
      premises:
      
      a) When request_module() is used userspace figures out an optimized
         version of module order for us.  Once it finds the modules it needs, as
         per depmod symbol dep map, it will finit_module() the respective
         modules which are needed for the original request_module() request.
      
      b) We have an optimization in place whereby if a kernel uses
         request_module() on a module already loaded we never bother userspace
         as the module already is loaded.  This is all handled by kernel/kmod.c.
      
      A few things to consider to help identify root causes of issues:
      
      0) kmod 19 has a broken heuristic for modules being assumed to be
         built-in to your kernel and will return 0 even though request_module()
         failed.  Upgrade to a newer version of kmod.
      
      1) A get_fs_type() call for "xfs" will request_module() for "fs-xfs",
         not for "xfs".  The optimization in kernel described in b) fails to
         catch if we have a lot of consecutive get_fs_type() calls.  The reason
         is the optimization in place does not look for aliases.  This means two
         consecutive get_fs_type() calls will bump kmod_concurrent, whereas
         request_module() will not.
      
      This one explanation why test case 0009 fails at least once for
      get_fs_type().
      
      2) If a module fails to load --- for whatever reason (kmod_concurrent
         limit reached, file not yet present due to rootfs switch, out of
         memory) we have a period of time during which module request for the
         same name either with request_module() or get_fs_type() will *also*
         fail to load even if the file for the module is ready.
      
      This explains why *multiple* NULLs are possible on test 0009.
      
      3) finit_module() consumes quite a bit of memory.
      
      4) Filesystems typically also have more dependent modules than other
         modules, its important to note though that even though a get_fs_type()
         call does not incur additional kmod_concurrent bumps, since userspace
         loads dependencies it finds it needs via finit_module_fd(), it *will*
         take much more memory to load a module with a lot of dependencies.
      
      Because of 3) and 4) we will easily run into out of memory failures with
      certain tests.  For instance test 0006 fails on qemu with 1024 MiB of RAM.
      It panics a box after reaping all userspace processes and still not
      having enough memory to reap.
      
      [arnd@arndb.de: add dependencies for test module]
        Link: http://lkml.kernel.org/r/20170630154834.3689272-1-arnd@arndb.de
      Link: http://lkml.kernel.org/r/20170628223155.26472-3-mcgrof@kernel.orgSigned-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d9c6a72d
  32. 12 Jul, 2017 1 commit
  33. 06 Jul, 2017 1 commit
    • Jeff Layton's avatar
      lib: add errseq_t type and infrastructure for handling it · 84cbadad
      Jeff Layton authored
      An errseq_t is a way of recording errors in one place, and allowing any
      number of "subscribers" to tell whether an error has been set again
      since a previous time.
      
      It's implemented as an unsigned 32-bit value that is managed with atomic
      operations. The low order bits are designated to hold an error code
      (max size of MAX_ERRNO). The upper bits are used as a counter.
      
      The API works with consumers sampling an errseq_t value at a particular
      point in time. Later, that value can be used to tell whether new errors
      have been set since that time.
      
      Note that there is a 1 in 512k risk of collisions here if new errors
      are being recorded frequently, since we have so few bits to use as a
      counter. To mitigate this, one bit is used as a flag to tell whether the
      value has been sampled since a new value was recorded. That allows
      us to avoid bumping the counter if no one has sampled it since it
      was last bumped.
      
      Later patches will build on this infrastructure to change how writeback
      errors are tracked in the kernel.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      84cbadad