1. 15 4月, 2015 3 次提交
    • P
      rcu: Control grace-period delays directly from value · 8d7dc928
      Paul E. McKenney 提交于
      In a misguided attempt to avoid an #ifdef, the use of the
      gp_init_delay module parameter was conditioned on the corresponding
      RCU_TORTURE_TEST_SLOW_INIT Kconfig variable, using IS_ENABLED() at
      the point of use in the code.  This meant that the compiler always saw
      the delay, which meant that RCU_TORTURE_TEST_SLOW_INIT_DELAY had to be
      unconditionally defined.  This in turn caused "make oldconfig" to ask
      pointless questions about the value of RCU_TORTURE_TEST_SLOW_INIT_DELAY
      in cases where it was not even used.
      
      This commit avoids these pointless questions by defining gp_init_delay
      under #ifdef.  In one branch, gp_init_delay is initialized to
      RCU_TORTURE_TEST_SLOW_INIT_DELAY and is also a module parameter (thus
      allowing boot-time modification), and in the other branch gp_init_delay
      is a const variable initialized by default to zero.
      
      This approach also simplifies the code at the delay point by eliminating
      the IS_DEFINED().  Because gp_init_delay is constant zero in the no-delay
      case intended for production use, the "gp_init_delay > 0" check causes
      the delay to become dead code, as desired in this case.  In addition,
      this commit replaces magic constant "10" with the preprocessor variable
      PER_RCU_NODE_PERIOD, which controls the number of grace periods that
      are allowed to elapse at full speed before a delay is inserted.
      
      Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
      Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      8d7dc928
    • V
      Kconfig: memtest: update number of test patterns up to 17 · 8d8cfb47
      Vladimir Murzin 提交于
      Additional test patterns for memtest were introduced since commit
      63823126 ("x86: memtest: add additional (regular) test patterns"),
      but looks like Kconfig was not updated that time.
      
      Update Kconfig entry with the actual number of maximum test patterns.
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8cfb47
    • V
      mm: move memtest under mm · 4a20799d
      Vladimir Murzin 提交于
      Memtest is a simple feature which fills the memory with a given set of
      patterns and validates memory contents, if bad memory regions is detected
      it reserves them via memblock API.  Since memblock API is widely used by
      other architectures this feature can be enabled outside of x86 world.
      
      This patch set promotes memtest to live under generic mm umbrella and
      enables memtest feature for arm/arm64.
      
      It was reported that this patch set was useful for tracking down an issue
      with some errant DMA on an arm64 platform.
      
      This patch (of 6):
      
      There is nothing platform dependent in the core memtest code, so other
      platforms might benefit from this feature too.
      
      [linux@roeck-us.net: MEMTEST depends on MEMBLOCK]
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Tested-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Paul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4a20799d
  2. 13 3月, 2015 2 次提交
    • J
      timekeeping: Add debugging checks to warn if we see delays · 3c17ad19
      John Stultz 提交于
      Recently there's been requests for better sanity
      checking in the time code, so that it's more clear
      when something is going wrong, since timekeeping issues
      could manifest in a large number of strange ways in
      various subsystems.
      
      Thus, this patch adds some extra infrastructure to
      add a check to update_wall_time() to print two new
      warnings:
      
       1) if we see the call delayed beyond the 'max_cycles'
          overflow point,
      
       2) or if we see the call delayed beyond the clocksource's
          'max_idle_ns' value, which is currently 50% of the
          overflow point.
      
      This extra infrastructure is conditional on
      a new CONFIG_DEBUG_TIMEKEEPING option, also
      added in this patch - default off.
      
      Tested this a bit by halting qemu for specified
      lengths of time to trigger the warnings.
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1426133800-29329-5-git-send-email-john.stultz@linaro.org
      [ Improved the changelog and the messages a bit. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      3c17ad19
    • P
      rcutorture: Default to grace-period-initialization delays · 186bea5d
      Paul E. McKenney 提交于
      Given that CPU-hotplug events are now applied only at the starts of
      grace periods, it makes sense to unconditionally enable slow grace-period
      initialization for rcutorture testing.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      186bea5d
  3. 12 3月, 2015 1 次提交
    • P
      rcu: Provide diagnostic option to slow down grace-period initialization · 37745d28
      Paul E. McKenney 提交于
      Grace-period initialization normally proceeds quite quickly, so
      that it is very difficult to reproduce races against grace-period
      initialization.  This commit therefore allows grace-period
      initialization to be artificially slowed down, increasing
      race-reproduction probability.  A pair of new Kconfig parameters are
      provided, CONFIG_RCU_TORTURE_TEST_SLOW_INIT to enable the slowdowns, and
      CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY to specify the number of jiffies
      of slowdown to apply.  A boot-time parameter named rcutree.gp_init_delay
      allows boot-time delay to be specified.  By default, no delay will be
      applied even if CONFIG_RCU_TORTURE_TEST_SLOW_INIT is set.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      37745d28
  4. 27 2月, 2015 1 次提交
  5. 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
  6. 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
  7. 13 2月, 2015 1 次提交
  8. 31 1月, 2015 1 次提交
  9. 26 1月, 2015 1 次提交
  10. 07 1月, 2015 2 次提交
    • P
      rcu: Set default to RCU_CPU_STALL_INFO=y · 68158fe2
      Paul E. McKenney 提交于
      The RCU_CPU_STALL_INFO code has been in for quite some time, and has
      proven reliable.  This commit therefore enables it by default.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      68158fe2
    • P
      rcu: Make SRCU optional by using CONFIG_SRCU · 83fe27ea
      Pranith Kumar 提交于
      SRCU is not necessary to be compiled by default in all cases. For tinification
      efforts not compiling SRCU unless necessary is desirable.
      
      The current patch tries to make compiling SRCU optional by introducing a new
      Kconfig option CONFIG_SRCU which is selected when any of the components making
      use of SRCU are selected.
      
      If we do not select CONFIG_SRCU, srcu.o will not be compiled at all.
      
         text    data     bss     dec     hex filename
         2007       0       0    2007     7d7 kernel/rcu/srcu.o
      
      Size of arch/powerpc/boot/zImage changes from
      
         text    data     bss     dec     hex filename
       831552   64180   23944  919676   e087c arch/powerpc/boot/zImage : before
       829504   64180   23952  917636   e0084 arch/powerpc/boot/zImage : after
      
      so the savings are about ~2000 bytes.
      Signed-off-by: NPranith Kumar <bobby.prani@gmail.com>
      CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      CC: Josh Triplett <josh@joshtriplett.org>
      CC: Lai Jiangshan <laijs@cn.fujitsu.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      [ paulmck: resolve conflict due to removal of arch/ia64/kvm/Kconfig. ]
      83fe27ea
  11. 14 12月, 2014 1 次提交
    • J
      mm/page_owner: keep track of page owners · 48c96a36
      Joonsoo Kim 提交于
      This is the page owner tracking code which is introduced so far ago.  It
      is resident on Andrew's tree, though, nobody tried to upstream so it
      remain as is.  Our company uses this feature actively to debug memory leak
      or to find a memory hogger so I decide to upstream this feature.
      
      This functionality help us to know who allocates the page.  When
      allocating a page, we store some information about allocation in extra
      memory.  Later, if we need to know status of all pages, we can get and
      analyze it from this stored information.
      
      In previous version of this feature, extra memory is statically defined in
      struct page, but, in this version, extra memory is allocated outside of
      struct page.  It enables us to turn on/off this feature at boottime
      without considerable memory waste.
      
      Although we already have tracepoint for tracing page allocation/free,
      using it to analyze page owner is rather complex.  We need to enlarge the
      trace buffer for preventing overlapping until userspace program launched.
      And, launched program continually dump out the trace buffer for later
      analysis and it would change system behaviour with more possibility rather
      than just keeping it in memory, so bad for debug.
      
      Moreover, we can use page_owner feature further for various purposes.  For
      example, we can use it for fragmentation statistics implemented in this
      patch.  And, I also plan to implement some CMA failure debugging feature
      using this interface.
      
      I'd like to give the credit for all developers contributed this feature,
      but, it's not easy because I don't know exact history.  Sorry about that.
      Below is people who has "Signed-off-by" in the patches in Andrew's tree.
      
      Contributor:
      Alexander Nyberg <alexn@dsv.su.se>
      Mel Gorman <mgorman@suse.de>
      Dave Hansen <dave@linux.vnet.ibm.com>
      Minchan Kim <minchan@kernel.org>
      Michal Nazarewicz <mina86@mina86.com>
      Andrew Morton <akpm@linux-foundation.org>
      Jungsoo Son <jungsoo.son@lge.com>
      Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Jungsoo Son <jungsoo.son@lge.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48c96a36
  12. 30 10月, 2014 1 次提交
  13. 29 10月, 2014 1 次提交
    • P
      rcu: Remove CONFIG_RCU_CPU_STALL_VERBOSE · 0eafa468
      Paul E. McKenney 提交于
      The CONFIG_RCU_CPU_STALL_VERBOSE Kconfig parameter causes preemptible
      RCU's CPU stall warnings to dump out any preempted tasks that are blocking
      the current RCU grace period.  This information is useful, and the default
      has been CONFIG_RCU_CPU_STALL_VERBOSE=y for some years.  It is therefore
      time for this commit to remove this Kconfig parameter, so that future
      kernel builds will always act as if CONFIG_RCU_CPU_STALL_VERBOSE=y.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      0eafa468
  14. 14 10月, 2014 1 次提交
    • V
      lib: rename TEST_MODULE to TEST_LKM · 8a6f0b47
      Valentin Rothberg 提交于
      The "_MODULE" suffix is reserved for tristates compiled as loadable kernel
      modules (LKM).  The "TEST_MODULE" feature thereby violates this
      convention.  The feature is used to compile the lib/test_module.c kernel
      module.
      
      Sadly this convention is not made explicit, but the Kconfig code documents
      it.  The following code (./scripts/kconfig/confdata.c) is used to generate
      the autoconf.h header file during the build process.  When a feature is
      selected as a kernel module ('m'), it is suffixed with "_MODULE" to
      indicate it.
      
      	switch (*value) {
      	case 'n':
      		break;
      	case 'm':
      		suffix = "_MODULE";
      		/* fall through */
      
      This causes problems for static code analysis, which assumes a consistent
      use of the "_MODULE" suffix.
      
      This patch renames the feature and its reference in a Makefile to
      "TEST_LKM", which still expresses the test of a LKM.
      Signed-off-by: NValentin Rothberg <valentinrothberg@gmail.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a6f0b47
  15. 27 9月, 2014 1 次提交
    • A
      bpf: mini eBPF library, test stubs and verifier testsuite · 3c731eba
      Alexei Starovoitov 提交于
      1.
      the library includes a trivial set of BPF syscall wrappers:
      int bpf_create_map(int key_size, int value_size, int max_entries);
      int bpf_update_elem(int fd, void *key, void *value);
      int bpf_lookup_elem(int fd, void *key, void *value);
      int bpf_delete_elem(int fd, void *key);
      int bpf_get_next_key(int fd, void *key, void *next_key);
      int bpf_prog_load(enum bpf_prog_type prog_type,
      		  const struct sock_filter_int *insns, int insn_len,
      		  const char *license);
      bpf_prog_load() stores verifier log into global bpf_log_buf[] array
      
      and BPF_*() macros to build instructions
      
      2.
      test stubs configure eBPF infra with 'unspec' map and program types.
      These are fake types used by user space testsuite only.
      
      3.
      verifier tests valid and invalid programs and expects predefined
      error log messages from kernel.
      40 tests so far.
      
      $ sudo ./test_verifier
       #0 add+sub+mul OK
       #1 unreachable OK
       #2 unreachable2 OK
       #3 out of range jump OK
       #4 out of range jump2 OK
       #5 test1 ld_imm64 OK
       ...
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c731eba
  16. 19 9月, 2014 1 次提交
    • A
      sched: Add default-disabled option to BUG() when stack end location is overwritten · 0d9e2632
      Aaron Tomlin 提交于
      Currently in the event of a stack overrun a call to schedule()
      does not check for this type of corruption. This corruption is
      often silent and can go unnoticed. However once the corrupted
      region is examined at a later stage, the outcome is undefined
      and often results in a sporadic page fault which cannot be
      handled.
      
      This patch checks for a stack overrun and takes appropriate
      action since the damage is already done, there is no point
      in continuing.
      Signed-off-by: NAaron Tomlin <atomlin@redhat.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: aneesh.kumar@linux.vnet.ibm.com
      Cc: dzickus@redhat.com
      Cc: bmr@redhat.com
      Cc: jcastillo@redhat.com
      Cc: oleg@redhat.com
      Cc: riel@redhat.com
      Cc: prarit@redhat.com
      Cc: jgh@redhat.com
      Cc: minchan@kernel.org
      Cc: mpe@ellerman.id.au
      Cc: tglx@linutronix.de
      Cc: rostedt@goodmis.org
      Cc: hannes@cmpxchg.org
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dan Streetman <ddstreet@ieee.org>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Lubomir Rintel <lkundrak@v3.sk>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/1410527779-8133-4-git-send-email-atomlin@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0d9e2632
  17. 30 8月, 2014 1 次提交
  18. 28 8月, 2014 1 次提交
  19. 13 8月, 2014 1 次提交
    • D
      locking/Documentation: Move locking related docs into Documentation/locking/ · 214e0aed
      Davidlohr Bueso 提交于
      Specifically:
        Documentation/locking/lockdep-design.txt
        Documentation/locking/lockstat.txt
        Documentation/locking/mutex-design.txt
        Documentation/locking/rt-mutex-design.txt
        Documentation/locking/rt-mutex.txt
        Documentation/locking/spinlocks.txt
        Documentation/locking/ww-mutex-design.txt
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: jason.low2@hp.com
      Cc: aswin@hp.com
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Chris Mason <clm@fb.com>
      Cc: Dan Streetman <ddstreet@ieee.org>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Jason Low <jason.low2@hp.com>
      Cc: Josef Bacik <jbacik@fusionio.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Lubomir Rintel <lkundrak@v3.sk>
      Cc: Masanari Iida <standby24x7@gmail.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: fengguang.wu@intel.com
      Link: http://lkml.kernel.org/r/1406752916-3341-6-git-send-email-davidlohr@hp.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      214e0aed
  20. 07 8月, 2014 1 次提交
    • A
      printk: rename DEFAULT_MESSAGE_LOGLEVEL · 42a9dc0b
      Alex Elder 提交于
      Commit a8fe19eb ("kernel/printk: use symbolic defines for console
      loglevels") makes consistent use of symbolic values for printk() log
      levels.
      
      The naming scheme used is different from the one used for
      DEFAULT_MESSAGE_LOGLEVEL though.  Change that symbol name to be
      MESSAGE_LOGLEVEL_DEFAULT for consistency.  And because the value of that
      symbol comes from a similarly-named config option, rename
      CONFIG_DEFAULT_MESSAGE_LOGLEVEL as well.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jan Kara <jack@suse.cz>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42a9dc0b
  21. 03 8月, 2014 1 次提交
  22. 31 7月, 2014 2 次提交
    • A
      Kbuild: Add a option to enable dwarf4 v2 · bfaf2dd3
      Andi Kleen 提交于
      I found that a lot of unresolvable variables when using gdb on the
      kernel become resolvable when dwarf4 is enabled. So add a Kconfig flag
      to enable it.
      
      It definitely increases the debug information size, but on the other
      hand this isn't so bad when debug fusion is used.
      
      v2: Use cc-option
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      bfaf2dd3
    • A
      kbuild: Support split debug info v4 · 866ced95
      Andi Kleen 提交于
      This is an alternative approach to lower the overhead of debug info
      (as we discussed a few days ago)
      
      gcc 4.7+ and newer binutils have a new "split debug info" debug info
      model where the debug info is only written once into central ".dwo" files.
      
      This avoids having to copy it around multiple times, from the object
      files to the final executable. It lowers the disk space
      requirements. In addition it defaults to compressed debug data.
      
      More details here: http://gcc.gnu.org/wiki/DebugFission
      
      This patch adds a new option to enable it. It has to be an option,
      because it'll undoubtedly break everyone's debuginfo packaging scheme.
      gdb/objdump/etc. all still work, if you have new enough versions.
      
      I don't see big compile wins (maybe a second or two faster or so), but the
      object dirs with debuginfo get significantly smaller. My standard kernel
      config (slightly bigger than defconfig) shrinks from 2.9G disk space
      to 1.1G objdir (with non reduced debuginfo). I presume if you are IO limited
      the compile time difference will be larger.
      
      Only problem I've seen so far is that it doesn't play well with older
      versions of ccache (apparently fixed, see
      https://bugzilla.samba.org/show_bug.cgi?id=10005)
      
      v2: various fixes from Dirk Gouders. Improve commit message slightly.
      v3: Fix clean rules and improve Kconfig slightly
      v4: Fix merge error in last version (Sam Ravnborg)
          Clarify description that it mainly helps disk size.
      Cc: Dirk Gouders <dirk@gouders.net>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      866ced95
  23. 24 7月, 2014 1 次提交
  24. 18 7月, 2014 1 次提交
  25. 10 7月, 2014 1 次提交
  26. 24 6月, 2014 1 次提交
  27. 22 6月, 2014 1 次提交
  28. 05 6月, 2014 2 次提交
  29. 14 5月, 2014 1 次提交
  30. 12 5月, 2014 1 次提交
  31. 05 5月, 2014 2 次提交
  32. 19 4月, 2014 1 次提交
  33. 02 4月, 2014 1 次提交