Skip to content
  1. Oct 10, 2017
  2. Oct 07, 2017
  3. Sep 26, 2017
  4. Sep 09, 2017
    • Dustin Brown's avatar
      ARM: 8691/1: Export save_stack_trace_tsk() · 9a3dc318
      Dustin Brown authored
      
      
      The kernel watchdog is a great debugging tool for finding tasks that
      consume a disproportionate amount of CPU time in contiguous chunks. One
      can imagine building a similar watchdog for arbitrary driver threads
      using save_stack_trace_tsk() and print_stack_trace(). However, this is
      not viable for dynamically loaded driver modules on ARM platforms
      because save_stack_trace_tsk() is not exported for those architectures.
      Export save_stack_trace_tsk() for the ARM architecture to align with
      x86 and support various debugging use cases such as arbitrary driver
      thread watchdog timers.
      
      Signed-off-by: default avatarDustin Brown <dustinb@codeaurora.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      9a3dc318
    • Matthew Wilcox's avatar
      ARM: implement memset32 & memset64 · fd1d3626
      Matthew Wilcox authored
      
      
      Reuse the existing optimised memset implementation to implement an
      optimised memset32 and memset64.
      
      Link: http://lkml.kernel.org/r/20170720184539.31609-5-willy@infradead.org
      Signed-off-by: default avatarMatthew Wilcox <mawilcox@microsoft.com>
      Reviewed-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fd1d3626
  5. Sep 05, 2017
  6. Sep 04, 2017
  7. Sep 02, 2017
  8. Sep 01, 2017
  9. Aug 31, 2017
  10. Aug 29, 2017
    • Mark Rutland's avatar
      ARM: 8692/1: mm: abort uaccess retries upon fatal signal · 746a272e
      Mark Rutland authored
      
      
      When there's a fatal signal pending, arm's do_page_fault()
      implementation returns 0. The intent is that we'll return to the
      faulting userspace instruction, delivering the signal on the way.
      
      However, if we take a fatal signal during fixing up a uaccess, this
      results in a return to the faulting kernel instruction, which will be
      instantly retried, resulting in the same fault being taken forever. As
      the task never reaches userspace, the signal is not delivered, and the
      task is left unkillable. While the task is stuck in this state, it can
      inhibit the forward progress of the system.
      
      To avoid this, we must ensure that when a fatal signal is pending, we
      apply any necessary fixup for a faulting kernel instruction. Thus we
      will return to an error path, and it is up to that code to make forward
      progress towards delivering the fatal signal.
      
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarSteve Capper <steve.capper@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      746a272e
    • Hoeun Ryu's avatar
      ARM: 8690/1: lpae: build TTB control register value from scratch in v7_ttb_setup · f26fee5f
      Hoeun Ryu authored
      
      
      Reading TTBCR in early boot stage might return the value of the previous
      kernel's configuration, especially in case of kexec. For example, if
      normal kernel (first kernel) had run on a configuration of PHYS_OFFSET <=
      PAGE_OFFSET and crash kernel (second kernel) is running on a configuration
      PHYS_OFFSET > PAGE_OFFSET, which can happen because it depends on the
      reserved area for crash kernel, reading TTBCR and using the value to OR
      other bit fields might be risky because it doesn't have a reset value for TTBCR.
      
      Suggested-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarHoeun Ryu <hoeun.ryu@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      f26fee5f
  11. Aug 28, 2017
  12. Aug 27, 2017
  13. Aug 26, 2017
    • Jiri Slaby's avatar
      futex: Remove duplicated code and fix undefined behaviour · 30d6e0a4
      Jiri Slaby authored
      There is code duplicated over all architecture's headers for
      futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
      and comparison of the result.
      
      Remove this duplication and leave up to the arches only the needed
      assembly which is now in arch_futex_atomic_op_inuser.
      
      This effectively distributes the Will Deacon's arm64 fix for undefined
      behaviour reported by UBSAN to all architectures. The fix was done in
      commit 5f16a046 (arm64: futex: Fix undefined behaviour with
      FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump.
      
      And as suggested by Thomas, check for negative oparg too, because it was
      also reported to cause undefined behaviour report.
      
      Note that s390 removed access_ok check in d12a2970
      
       ("s390/uaccess:
      remove pointless access_ok() checks") as access_ok there returns true.
      We introduce it back to the helper for the sake of simplicity (it gets
      optimized away anyway).
      
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> [s390]
      Acked-by: Chris Metcalf <cmetcalf@mellanox.com> [for tile]
      Reviewed-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      Reviewed-by: Will Deacon <will.deacon@arm.com> [core/arm64]
      Cc: linux-mips@linux-mips.org
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: peterz@infradead.org
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: sparclinux@vger.kernel.org
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: linux-s390@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: linux-hexagon@vger.kernel.org
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: linux-snps-arc@lists.infradead.org
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-xtensa@linux-xtensa.org
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: openrisc@lists.librecores.org
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-parisc@vger.kernel.org
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: linux-alpha@vger.kernel.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: "David S. Miller" <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/20170824073105.3901-1-jslaby@suse.cz
      30d6e0a4
  14. Aug 25, 2017
  15. Aug 24, 2017
  16. Aug 23, 2017