1. 05 Jul, 2015 1 commit
  2. 22 Jun, 2015 1 commit
  3. 15 Jun, 2015 1 commit
  4. 08 Jun, 2015 1 commit
  5. 01 Jun, 2015 1 commit
  6. 25 May, 2015 1 commit
  7. 18 May, 2015 1 commit
  8. 10 May, 2015 1 commit
  9. 04 May, 2015 1 commit
  10. 29 Apr, 2015 1 commit
  11. 27 Apr, 2015 2 commits
    • Paul Cercueil's avatar
      Makefile: Fix detection of clang when cross-compiling · ee4eb20d
      Paul Cercueil authored
      When the host's C compiler is clang, and when attempting to
      cross-compile Linux e.g. to MIPS with mipsel-linux-gcc, the Makefile
      would incorrectly detect the use of clang, which resulted in
      clang-specific flags being passed to mipsel-linux-gcc.
      This can be verified under Debian by installing the "clang" package,
      and then using it as the default compiler with:
      sudo update-alternatives --config cc
      This patch moves the detection of clang after the $(CC) variable is
      initialized to the name of the cross-compiler, so that the check applies
      to the cross-compiler and not the host's C compiler.
      v2: Move the detection of clang after the inclusion of the
      arch/*/Makefile (as they might set $(CROSS_COMPILE))
      Signed-off-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
    • Linus Torvalds's avatar
      Linux 4.1-rc1 · b787f68c
      Linus Torvalds authored
  12. 12 Apr, 2015 1 commit
  13. 09 Apr, 2015 1 commit
    • Anton Blanchard's avatar
      jump_label: Allow jump labels to be used in assembly · c0ccf6f9
      Anton Blanchard authored
      To use jump labels in assembly we need the HAVE_JUMP_LABEL
      define, so we select a fallback version if the toolchain does
      not support them.
      Modify linux/jump_label.h so it can be included by assembly
      files. We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: benh@kernel.crashing.org
      Cc: catalin.marinas@arm.com
      Cc: davem@davemloft.net
      Cc: heiko.carstens@de.ibm.com
      Cc: jbaron@akamai.com
      Cc: linux@arm.linux.org.uk
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: liuj97@gmail.com
      Cc: mgorman@suse.de
      Cc: mmarek@suse.cz
      Cc: mpe@ellerman.id.au
      Cc: paulus@samba.org
      Cc: ralf@linux-mips.org
      Cc: rostedt@goodmis.org
      Cc: schwidefsky@de.ibm.com
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1428551492-21977-2-git-send-email-anton@samba.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  14. 06 Apr, 2015 1 commit
  15. 02 Apr, 2015 1 commit
  16. 29 Mar, 2015 1 commit
  17. 24 Mar, 2015 1 commit
  18. 22 Mar, 2015 1 commit
  19. 16 Mar, 2015 1 commit
  20. 08 Mar, 2015 1 commit
  21. 03 Mar, 2015 1 commit
  22. 23 Feb, 2015 1 commit
    • Linus Torvalds's avatar
      Linux 4.0-rc1 · c517d838
      Linus Torvalds authored
      .. after extensive statistical analysis of my G+ polling, I've come to
      the inescapable conclusion that internet polls are bad.
      Big surprise.
      But "Hurr durr I'ma sheep" trounced "I like online polls" by a 62-to-38%
      margin, in a poll that people weren't even supposed to participate in.
      Who can argue with solid numbers like that? 5,796 votes from people who
      can't even follow the most basic directions?
      In contrast, "v4.0" beat out "v3.20" by a slimmer margin of 56-to-44%,
      but with a total of 29,110 votes right now.
      Now, arguably, that vote spread is only about 3,200 votes, which is less
      than the almost six thousand votes that the "please ignore" poll got, so
      it could be considered noise.
      But hey, I asked, so I'll honor the votes.
  23. 17 Feb, 2015 1 commit
    • Jan Kiszka's avatar
      scripts/gdb: add infrastructure · 3ee7b3fa
      Jan Kiszka authored
      This provides the basic infrastructure to load kernel-specific python
      helper scripts when debugging the kernel in gdb.
      The loading mechanism is based on gdb loading for <objfile>-gdb.py when
      opening <objfile>.  Therefore, this places a corresponding link to the
      main helper script into the output directory that contains vmlinux.
      The main scripts will pull in submodules containing Linux specific gdb
      commands and functions.  To avoid polluting the source directory with
      compiled python modules, we link to them from the object directory.
      Due to gdb.parse_and_eval and string redirection for gdb.execute, we
      depend on gdb >= 7.2.
      This feature is enabled via CONFIG_GDB_SCRIPTS.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Acked-by: Michal Marek <mmarek@suse.cz>		[kbuild stuff]
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  24. 14 Feb, 2015 1 commit
    • Andrey Ryabinin's avatar
      kasan: add kernel address sanitizer infrastructure · 0b24becc
      Andrey Ryabinin authored
      Kernel Address sanitizer (KASan) is a dynamic memory error detector.  It
      provides fast and comprehensive solution for finding use-after-free and
      out-of-bounds bugs.
      KASAN uses compile-time instrumentation for checking every memory access,
      therefore GCC > v4.9.2 required.  v4.9.2 almost works, but has issues with
      putting symbol aliases into the wrong section, which breaks kasan
      instrumentation of globals.
      This patch only adds infrastructure for kernel address sanitizer.  It's
      not available for use yet.  The idea and some code was borrowed from [1].
      Basic idea:
      The main idea of KASAN is to use shadow memory to record whether each byte
      of memory is safe to access or not, and use compiler's instrumentation to
      check the shadow memory on each memory access.
      Address sanitizer uses 1/8 of the memory addressable in kernel for shadow
      memory and uses direct mapping with a scale and offset to translate a
      memory address to its corresponding shadow address.
      Here is function to translate address to corresponding shadow address:
           unsigned long kasan_mem_to_shadow(unsigned long addr)
                      return (addr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET;
      So for every 8 bytes there is one corresponding byte of shadow memory.
      The following encoding used for each shadow byte: 0 means that all 8 bytes
      of the corresponding memory region are valid for access; k (1 <= k <= 7)
      means that the first k bytes are valid for access, and other (8 - k) bytes
      are not; Any negative value indicates that the entire 8-bytes are
      inaccessible.  Different negative values used to distinguish between
      different kinds of inaccessible memory (redzones, freed memory) (see
      To be able to detect accesses to bad memory we need a special compiler.
      Such compiler inserts a specific function calls (__asan_load*(addr),
      __asan_store*(addr)) before each memory access of size 1, 2, 4, 8 or 16.
      These functions check whether memory region is valid to access or not by
      checking corresponding shadow memory.  If access is not valid an error
      Historical background of the address sanitizer from Dmitry Vyukov:
      	"We've developed the set of tools, AddressSanitizer (Asan),
      	ThreadSanitizer and MemorySanitizer, for user space. We actively use
      	them for testing inside of Google (continuous testing, fuzzing,
      	running prod services). To date the tools have found more than 10'000
      	scary bugs in Chromium, Google internal codebase and various
      	open-source projects (Firefox, OpenSSL, gcc, clang, ffmpeg, MySQL and
      	lots of others): [2] [3] [4].
      	The tools are part of both gcc and clang compilers.
      	We have not yet done massive testing under the Kernel AddressSanitizer
      	(it's kind of chicken and egg problem, you need it to be upstream to
      	start applying it extensively). To date it has found about 50 bugs.
      	Bugs that we've found in upstream kernel are listed in [5].
      	We've also found ~20 bugs in out internal version of the kernel. Also
      	people from Samsung and Oracle have found some.
      	As others noted, the main feature of AddressSanitizer is its
      	performance due to inline compiler instrumentation and simple linear
      	shadow memory. User-space Asan has ~2x slowdown on computational
      	programs and ~2x memory consumption increase. Taking into account that
      	kernel usually consumes only small fraction of CPU and memory when
      	running real user-space programs, I would expect that kernel Asan will
      	have ~10-30% slowdown and similar memory consumption increase (when we
      	finish all tuning).
      	I agree that Asan can well replace kmemcheck. We have plans to start
      	working on Kernel MemorySanitizer that finds uses of unitialized
      	memory. Asan+Msan will provide feature-parity with kmemcheck. As
      	others noted, Asan will unlikely replace debug slab and pagealloc that
      	can be enabled at runtime. Asan uses compiler instrumentation, so even
      	if it is disabled, it still incurs visible overheads.
      	Asan technology is easily portable to other architectures. Compiler
      	instrumentation is fully portable. Runtime has some arch-dependent
      	parts like shadow mapping and atomic operation interception. They are
      	relatively easy to port."
      Comparison with other debugging features:
        - KASan can do almost everything that kmemcheck can.  KASan uses
          compile-time instrumentation, which makes it significantly faster than
          kmemcheck.  The only advantage of kmemcheck over KASan is detection of
          uninitialized memory reads.
          Some brief performance testing showed that kasan could be
          x500-x600 times faster than kmemcheck:
      $ netperf -l 30
      		MIGRATED TCP STREAM TEST from ( port 0 AF_INET to localhost ( port 0 AF_INET
      		Recv   Send    Send
      		Socket Socket  Message  Elapsed
      		Size   Size    Size     Time     Throughput
      		bytes  bytes   bytes    secs.    10^6bits/sec
      no debug:	87380  16384  16384    30.00    41624.72
      kasan inline:	87380  16384  16384    30.00    12870.54
      kasan outline:	87380  16384  16384    30.00    10586.39
      kmemcheck: 	87380  16384  16384    30.03      20.23
        - Also kmemcheck couldn't work on several CPUs.  It always sets
          number of CPUs to 1.  KASan doesn't have such limitation.
      	- KASan is slower than DEBUG_PAGEALLOC, but KASan works on sub-page
      	  granularity level, so it able to find more bugs.
      SLUB_DEBUG (poisoning, redzones):
      	- SLUB_DEBUG has lower overhead than KASan.
      	- SLUB_DEBUG in most cases are not able to detect bad reads,
      	  KASan able to detect both reads and writes.
      	- In some cases (e.g. redzone overwritten) SLUB_DEBUG detect
      	  bugs only on allocation/freeing of object. KASan catch
      	  bugs right before it will happen, so we always know exact
      	  place of first bad read/write.
      [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
      [2] https://code.google.com/p/address-sanitizer/wiki/FoundBugs
      [3] https://code.google.com/p/thread-sanitizer/wiki/FoundBugs
      [4] https://code.google.com/p/memory-sanitizer/wiki/FoundBugs
      [5] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel#Trophies
      Based on work by Andrey Konovalov.
      Signed-off-by: default avatarAndrey Ryabinin <a.ryabinin@samsung.com>
      Acked-by: default avatarMichal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarAndrey Konovalov <adech.fo@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  25. 09 Feb, 2015 1 commit
  26. 02 Feb, 2015 1 commit
  27. 29 Jan, 2015 1 commit
  28. 26 Jan, 2015 1 commit
  29. 18 Jan, 2015 1 commit
  30. 11 Jan, 2015 1 commit
  31. 08 Jan, 2015 3 commits
  32. 06 Jan, 2015 1 commit
  33. 29 Dec, 2014 1 commit
  34. 21 Dec, 2014 1 commit
  35. 07 Dec, 2014 1 commit
  36. 01 Dec, 2014 1 commit
  37. 28 Nov, 2014 1 commit