Skip to content
Snippets Groups Projects
  1. Nov 13, 2013
  2. Sep 27, 2013
    • Richard Weinberger's avatar
      um: Implement probe_kernel_read() · 4fdaa3d4
      Richard Weinberger authored
      
      commit f75b1b1b upstream.
      
      UML needs it's own probe_kernel_read() to handle kernel
      mode faults correctly.
      The implementation uses mincore() on the host side to detect
      whether a page is owned by the UML kernel process.
      
      This fixes also a possible crash when sysrq-t is used.
      Starting with 3.10 sysrq-t calls probe_kernel_read() to
      read details from the kernel workers. As kernel worker are
      completely async pointers may turn NULL while reading them.
      
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Cc: <stian@nixia.no>
      Cc: <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fdaa3d4
  3. May 01, 2013
    • Tejun Heo's avatar
      dump_stack: consolidate dump_stack() implementations and unify their behaviors · 196779b9
      Tejun Heo authored
      
      Both dump_stack() and show_stack() are currently implemented by each
      architecture.  show_stack(NULL, NULL) dumps the backtrace for the
      current task as does dump_stack().  On some archs, dump_stack() prints
      extra information - pid, utsname and so on - in addition to the
      backtrace while the two are identical on other archs.
      
      The usages in arch-independent code of the two functions indicate
      show_stack(NULL, NULL) should print out bare backtrace while
      dump_stack() is used for debugging purposes when something went wrong,
      so it does make sense to print additional information on the task which
      triggered dump_stack().
      
      There's no reason to require archs to implement two separate but mostly
      identical functions.  It leads to unnecessary subtle information.
      
      This patch expands the dummy fallback dump_stack() implementation in
      lib/dump_stack.c such that it prints out debug information (taken from
      x86) and invokes show_stack(NULL, NULL) and drops arch-specific
      dump_stack() implementations in all archs except blackfin.  Blackfin's
      dump_stack() does something wonky that I don't understand.
      
      Debug information can be printed separately by calling
      dump_stack_print_info() so that arch-specific dump_stack()
      implementation can still emit the same debug information.  This is used
      in blackfin.
      
      This patch brings the following behavior changes.
      
      * On some archs, an extra level in backtrace for show_stack() could be
        printed.  This is because the top frame was determined in
        dump_stack() on those archs while generic dump_stack() can't do that
        reliably.  It can be compensated by inlining dump_stack() but not
        sure whether that'd be necessary.
      
      * Most archs didn't use to print debug info on dump_stack().  They do
        now.
      
      An example WARN dump follows.
      
       WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
       Hardware name: empty
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #9
        0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
        ffffffff8108f50f ffffffff82228240 0000000000000040 ffffffff8234a03c
        0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
       Call Trace:
        [<ffffffff81c614dc>] dump_stack+0x19/0x1b
        [<ffffffff8108f50f>] warn_slowpath_common+0x7f/0xc0
        [<ffffffff8108f56a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff8234a071>] init_workqueues+0x35/0x505
        ...
      
      v2: CPU number added to the generic debug info as requested by s390
          folks and dropped the s390 specific dump_stack().  This loses %ksp
          from the debug message which the maintainers think isn't important
          enough to keep the s390-specific dump_stack() implementation.
      
          dump_stack_print_info() is moved to kernel/printk.c from
          lib/dump_stack.c.  Because linkage is per objecct file,
          dump_stack_print_info() living in the same lib file as generic
          dump_stack() means that archs which implement custom dump_stack()
          - at this point, only blackfin - can't use dump_stack_print_info()
          as that will bring in the generic version of dump_stack() too.  v1
          The v1 patch broke build on blackfin due to this issue.  The build
          breakage was reported by Fengguang Wu.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>	[s390 bits]
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: Richard Kuo <rkuo@codeaurora.org>		[hexagon bits]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      196779b9
  4. Apr 30, 2013
  5. Apr 29, 2013
  6. Apr 17, 2013
  7. Feb 03, 2013
  8. Dec 19, 2012
  9. Nov 29, 2012
  10. Oct 12, 2012
  11. Oct 09, 2012
  12. Oct 01, 2012
  13. Sep 27, 2012
  14. Sep 20, 2012
  15. Aug 01, 2012
  16. Jul 19, 2012
    • Theodore Ts'o's avatar
      um: remove IRQF_SAMPLE_RANDOM which is now a no-op · aab94460
      Theodore Ts'o authored
      
      With the changes in the random tree, IRQF_SAMPLE_RANDOM is now a
      no-op; interrupt randomness is now collected unconditionally in a very
      low-overhead fashion; see commit 775f4b29.  The IRQF_SAMPLE_RANDOM
      flag was scheduled to be removed in 2009 on the
      feature-removal-schedule, so this patch is preparation for the final
      removal of this flag.
      
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Richard Weinberger <richard@nod.at>
      aab94460
  17. Jun 01, 2012
Loading