1. 25 5月, 2015 1 次提交
  2. 19 5月, 2015 1 次提交
  3. 11 5月, 2015 1 次提交
  4. 04 5月, 2015 1 次提交
  5. 27 4月, 2015 1 次提交
  6. 13 4月, 2015 1 次提交
  7. 09 4月, 2015 1 次提交
    • A
      jump_label: Allow jump labels to be used in assembly · c0ccf6f9
      Anton Blanchard 提交于
      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: NAnton Blanchard <anton@samba.org>
      Acked-by: NPeter 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: NIngo Molnar <mingo@kernel.org>
      c0ccf6f9
  8. 07 4月, 2015 1 次提交
  9. 02 4月, 2015 1 次提交
  10. 30 3月, 2015 1 次提交
  11. 25 3月, 2015 1 次提交
  12. 23 3月, 2015 1 次提交
  13. 16 3月, 2015 1 次提交
  14. 09 3月, 2015 1 次提交
  15. 04 3月, 2015 1 次提交
  16. 23 2月, 2015 1 次提交
    • L
      Linux 4.0-rc1 · c517d838
      Linus Torvalds 提交于
      .. 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.
      c517d838
  17. 18 2月, 2015 1 次提交
    • J
      scripts/gdb: add infrastructure · 3ee7b3fa
      Jan Kiszka 提交于
      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: NJan 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ee7b3fa
  18. 14 2月, 2015 1 次提交
    • A
      kasan: add kernel address sanitizer infrastructure · 0b24becc
      Andrey Ryabinin 提交于
      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;
           }
      
      where KASAN_SHADOW_SCALE_SHIFT = 3.
      
      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
      mm/kasan/kasan.h).
      
      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
      printed.
      
      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:
      ========================================
      
      KMEMCHECK:
      
        - 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 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) 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.
      
      DEBUG_PAGEALLOC:
      	- 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: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Acked-by: NMichal Marek <mmarek@suse.cz>
      Signed-off-by: NAndrey 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b24becc
  19. 09 2月, 2015 1 次提交
  20. 02 2月, 2015 1 次提交
  21. 29 1月, 2015 1 次提交
  22. 26 1月, 2015 1 次提交
  23. 18 1月, 2015 1 次提交
  24. 12 1月, 2015 1 次提交
  25. 09 1月, 2015 1 次提交
    • M
      Makefile: include arch/*/include/generated/uapi before .../generated · 90ac086b
      Michal Marek 提交于
      The introduction of the uapi directories in v3.7-rc1 moved some of the
      generated headers from arch/*/include/generated to the uapi directory,
      keeping the #include directives intact.
      
      This creates a problem when bisecting, because the unversioned files are
      not cleaned automatically by git and the compiler might include stale
      headers as a result.  Instead of cleaning them in the Makefiles, promote
      arch/*/include/generated/uapi in the search path.  Under normal
      circumstances, there is no overlap between this uapi subdirectory and
      its parent, so the include choices remain the same.  We keep
      arch/*/include/generated/uapi in the USERINCLUDE variable so that it is
      usable standalone.
      
      Note that we cannot completely swap the order of the uapi and
      kernel-only directories, since the headers in include/uapi/asm-generic
      are meant to be wrapped by their include/asm-generic counterparts when
      building kernel code.
      Reported-by: N"Nicholas A. Bellinger" <nab@linux-iscsi.org>
      Reported-by: NDavid Drysdale <dmd@lurklurk.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      90ac086b
  26. 08 1月, 2015 2 次提交
  27. 06 1月, 2015 1 次提交
  28. 29 12月, 2014 1 次提交
  29. 21 12月, 2014 1 次提交
  30. 08 12月, 2014 1 次提交
  31. 01 12月, 2014 1 次提交
  32. 28 11月, 2014 3 次提交
  33. 26 11月, 2014 1 次提交
  34. 24 11月, 2014 1 次提交
  35. 17 11月, 2014 1 次提交
  36. 16 11月, 2014 1 次提交
    • K
      kernel: use the gnu89 standard explicitly · 51b97e35
      Kirill A. Shutemov 提交于
      Sasha Levin reports:
       "gcc5 changes the default standard to c11, which makes kernel build
        unhappy
      
        Explicitly define the kernel standard to be gnu89 which should keep
        everything working exactly like it was before gcc5"
      
      There are multiple small issues with the new default, but the biggest
      issue seems to be that the old - and very useful - GNU extension to
      allow a cast in front of an initializer has gone away.
      
      Patch updated by Kirill:
       "I'm pretty sure all gcc versions you can build kernel with supports
        -std=gnu89.  cc-option is redunrant.
      
        We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me"
      
      Note by Andrew Pinski:
       "Yes it was reported and both problems relating to this extension has
        been added to gnu99 and gnu11.  Though there are other issues with the
        kernel dealing with extern inline have different semantics between
        gnu89 and gnu99/11"
      
      End result: we may be able to move up to a newer stdc model eventually,
      but right now the newer models have some annoying deficiencies, so the
      traditional "gnu89" model ends up being the preferred one.
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Singed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      51b97e35
  37. 10 11月, 2014 1 次提交