1. 15 Sep, 2016 2 commits
    • Josh Poimboeuf's avatar
      x86/dumpstack: Add get_stack_info() interface · cb76c939
      Josh Poimboeuf authored
      valid_stack_ptr() is buggy: it assumes that all stacks are of size
      THREAD_SIZE, which is not true for exception stacks.  So the
      walk_stack() callbacks will need to know the location of the beginning
      of the stack as well as the end.
      
      Another issue is that in general the various features of a stack (type,
      size, next stack pointer, description string) are scattered around in
      various places throughout the stack dump code.
      
      Encapsulate all that information in a single place with a new stack_info
      struct and a get_stack_info() interface.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nilay Vaish <nilayvaish@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/8164dd0db96b7e6a279fa17ae5e6dc375eecb4a9.1473905218.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      cb76c939
    • Josh Poimboeuf's avatar
      x86/dumpstack: Simplify in_exception_stack() · 9c003907
      Josh Poimboeuf authored
      in_exception_stack() does some bad, bad things just so the unwinder can
      print different values for different areas of the debug exception stack.
      
      There's no need to clarify where exactly on the stack it is.  Just print
      "#DB" and be done with it.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nilay Vaish <nilayvaish@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/e91cb410169dd576678dd427c35efb716fd0cee1.1473905218.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      9c003907
  2. 14 Sep, 2016 1 commit
    • Josh Poimboeuf's avatar
      x86/dumpstack: Allow preemption in show_stack_log_lvl() and dump_trace() · cfeeed27
      Josh Poimboeuf authored
      show_stack_log_lvl() and dump_trace() are already preemption safe:
      
      - If they're running in irq or exception context, preemption is already
        disabled and the percpu stack pointers can be trusted.
      
      - If they're running with preemption enabled, they must be running on
        the task stack anyway, so it doesn't matter if they're comparing the
        stack pointer against a percpu stack pointer from this CPU or another
        one: either way it won't match.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nilay Vaish <nilayvaish@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/a0ca0b1044eca97d4f0ec7c1619cf80b3b65560d.1473371307.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      cfeeed27
  3. 13 Sep, 2016 2 commits
  4. 08 Sep, 2016 9 commits
  5. 24 Aug, 2016 20 commits
  6. 21 Aug, 2016 3 commits
  7. 20 Aug, 2016 2 commits
    • Helge Deller's avatar
      parisc: Fix order of EREFUSED define in errno.h · 3eb53b20
      Helge Deller authored
      When building gccgo in userspace, errno.h gets parsed and the go include file
      sysinfo.go is generated.
      
      Since EREFUSED is defined to the same value as ECONNREFUSED, and ECONNREFUSED
      is defined later on in errno.h, this leads to go complaining that EREFUSED
      isn't defined yet.
      
      Fix this trivial problem by moving the define of EREFUSED down after
      ECONNREFUSED in errno.h (and clean up the indenting while touching this line).
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      3eb53b20
    • Helge Deller's avatar
      parisc: Fix automatic selection of cr16 clocksource · ae141830
      Helge Deller authored
      Commit 54b66800 (parisc: Add native high-resolution sched_clock()
      implementation) added support to use the CPU-internal cr16 counters as reliable
      clocksource with the help of HAVE_UNSTABLE_SCHED_CLOCK.
      
      Sadly the commit missed to remove the hack which prevented cr16 to become the
      default clocksource even on SMP systems.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # 4.7+
      ae141830
  8. 19 Aug, 2016 1 commit
    • Linus Torvalds's avatar
      Make the hardened user-copy code depend on having a hardened allocator · 6040e576
      Linus Torvalds authored
      The kernel test robot reported a usercopy failure in the new hardened
      sanity checks, due to a page-crossing copy of the FPU state into the
      task structure.
      
      This happened because the kernel test robot was testing with SLOB, which
      doesn't actually do the required book-keeping for slab allocations, and
      as a result the hardening code didn't realize that the task struct
      allocation was one single allocation - and the sanity checks fail.
      
      Since SLOB doesn't even claim to support hardening (and you really
      shouldn't use it), the straightforward solution is to just make the
      usercopy hardening code depend on the allocator supporting it.
      Reported-by: default avatarkernel test robot <xiaolong.ye@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6040e576