1. 21 Jan, 2013 1 commit
  2. 12 Jan, 2013 1 commit
    • Rusty Russell's avatar
      module: put modules in list much earlier. · 1fb9341a
      Rusty Russell authored
      Prarit's excellent bug report:
      > In recent Fedora releases (F17 & F18) some users have reported seeing
      > messages similar to
      > [   15.478160] kvm: Could not allocate 304 bytes percpu data
      > [   15.478174] PERCPU: allocation failed, size=304 align=32, alloc from
      > reserved chunk failed
      > during system boot.  In some cases, users have also reported seeing this
      > message along with a failed load of other modules.
      > What is happening is systemd is loading an instance of the kvm module for
      > each cpu found (see commit e9bda3b3).  When the module load occurs the kernel
      > currently allocates the modules percpu data area prior to checking to see
      > if the module is already loaded or is in the process of being loaded.  If
      > the module is already loaded, or finishes load, the module loading code
      > releases the current instance's module's percpu data.
      Now we have a new state MODULE_STATE_UNFORMED, we can insert the
      module into the list (and thus guarantee its uniqueness) before we
      allocate the per-cpu region.
      Reported-by: 's avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: 's avatarRusty Russell <rusty@rustcorp.com.au>
      Tested-by: 's avatarPrarit Bhargava <prarit@redhat.com>
  3. 26 Jan, 2012 1 commit
    • Prarit Bhargava's avatar
      bugs, x86: Fix printk levels for panic, softlockups and stack dumps · b0f4c4b3
      Prarit Bhargava authored
      rsyslog will display KERN_EMERG messages on a connected
      terminal.  However, these messages are useless/undecipherable
      for a general user.
      For example, after a softlockup we get:
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Call Trace:
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89
       d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89
      This happens because the printk levels for these messages are
      incorrect. Only an informational message should be displayed on
      a terminal.
      I modified the printk levels for various messages in the kernel
      and tested the output by using the drivers/misc/lkdtm.c kernel
      modules (ie, softlockups, panics, hard lockups, etc.) and
      confirmed that the console output was still the same and that
      the output to the terminals was correct.
      For example, in the case of a softlockup we now see the much
      more informative:
       Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ...
       BUG: soft lockup - CPU4 stuck for 60s!
      instead of the above confusing messages.
      AFAICT, the messages no longer have to be KERN_EMERG.  In the
      most important case of a panic we set console_verbose().  As for
      the other less severe cases the correct data is output to the
      console and /var/log/messages.
      Successfully tested by me using the drivers/misc/lkdtm.c module.
      Signed-off-by: 's avatarPrarit Bhargava <prarit@redhat.com>
      Cc: dzickus@redhat.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.comSigned-off-by: 's avatarIngo Molnar <mingo@elte.hu>
  4. 05 Oct, 2010 1 commit
    • Linus Torvalds's avatar
      modules: Fix module_bug_list list corruption race · 5336377d
      Linus Torvalds authored
      With all the recent module loading cleanups, we've minimized the code
      that sits under module_mutex, fixing various deadlocks and making it
      possible to do most of the module loading in parallel.
      However, that whole conversion totally missed the rather obscure code
      that adds a new module to the list for BUG() handling.  That code was
      doubly obscure because (a) the code itself lives in lib/bugs.c (for
      dubious reasons) and (b) it gets called from the architecture-specific
      "module_finalize()" rather than from generic code.
      Calling it from arch-specific code makes no sense what-so-ever to begin
      with, and is now actively wrong since that code isn't protected by the
      module loading lock any more.
      So this commit moves the "module_bug_{finalize,cleanup}()" calls away
      from the arch-specific code, and into the generic code - and in the
      process protects it with the module_mutex so that the list operations
      are now safe.
      Future fixups:
       - move the module list handling code into kernel/module.c where it
       - get rid of 'module_bug_list' and just use the regular list of modules
         (called 'modules' - imagine that) that we already create and maintain
         for other reasons.
      Reported-and-tested-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Adrian Bunk <bunk@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 11 Aug, 2010 2 commits
  6. 19 May, 2010 1 commit
  7. 16 Dec, 2008 1 commit
  8. 04 Jul, 2008 1 commit
  9. 16 Jul, 2007 1 commit
    • Heiko Carstens's avatar
      generic bug: use show_regs() instead of dump_stack() · 608e2619
      Heiko Carstens authored
      The current generic bug implementation has a call to dump_stack() in case a
      WARN_ON(whatever) gets hit.  Since report_bug(), which calls dump_stack(),
      gets called from an exception handler we can do better: just pass the
      pt_regs structure to report_bug() and pass it to show_regs() in case of a
      warning.  This will give more debug informations like register contents,
      etc...  In addition this avoids some pointless lines that dump_stack()
      emits, since it includes a stack backtrace of the exception handler which
      is of no interest in case of a warning.  E.g.  on s390 the following lines
      are currently always present in a stack backtrace if dump_stack() gets
      called from report_bug():
       [<000000000001517a>] show_trace+0x92/0xe8)
       [<0000000000015270>] show_stack+0xa0/0xd0
       [<00000000000152ce>] dump_stack+0x2e/0x3c
       [<0000000000195450>] report_bug+0x98/0xf8
       [<0000000000016cc8>] illegal_op+0x1fc/0x21c
       [<00000000000227d6>] sysc_return+0x0/0x10
      Acked-by: 's avatarJeremy Fitzhardinge <jeremy@goop.org>
      Acked-by: 's avatarHaavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Kyle McMartin <kyle@parisc-linux.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: 's avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 08 Dec, 2006 1 commit
    • Jeremy Fitzhardinge's avatar
      [PATCH] Generic BUG implementation · 7664c5a1
      Jeremy Fitzhardinge authored
      This patch adds common handling for kernel BUGs, for use by architectures as
      they wish.  The code is derived from arch/powerpc.
      The advantages of having common BUG handling are:
       - consistent BUG reporting across architectures
       - shared implementation of out-of-line file/line data
       - implement CONFIG_DEBUG_BUGVERBOSE consistently
      This means that in inline impact of BUG is just the illegal instruction
      itself, which is an improvement for i386 and x86-64.
      A BUG is represented in the instruction stream as an illegal instruction,
      which has file/line information associated with it.  This extra information is
      stored in the __bug_table section in the ELF file.
      When the kernel gets an illegal instruction, it first confirms it might
      possibly be from a BUG (ie, in kernel mode, the right illegal instruction).
      It then calls report_bug().  This searches __bug_table for a matching
      instruction pointer, and if found, prints the corresponding file/line
      information.  If report_bug() determines that it wasn't a BUG which caused the
      trap, it returns BUG_TRAP_TYPE_NONE.
      Some architectures (powerpc) implement WARN using the same mechanism; if the
      illegal instruction was the result of a WARN, then report_bug(Q) returns
      CONFIG_DEBUG_BUGVERBOSE; otherwise it returns BUG_TRAP_TYPE_BUG.
      lib/bug.c keeps a list of loaded modules which can be searched for __bug_table
      entries.  The architecture must call
      module_bug_finalize()/module_bug_cleanup() from its corresponding
      module_finalize/cleanup functions.
      Unsetting CONFIG_DEBUG_BUGVERBOSE will reduce the kernel size by some amount.
      At the very least, filename and line information will not be recorded for each
      but, but architectures may decide to store no extra information per BUG at
      Unfortunately, gcc doesn't have a general way to mark an asm() as noreturn, so
      architectures will generally have to include an infinite loop (or similar) in
      the BUG code, so that gcc knows execution won't continue beyond that point.
      gcc does have a __builtin_trap() operator which may be useful to achieve the
      same effect, unfortunately it cannot be used to actually implement the BUG
      itself, because there's no way to get the instruction's address for use in
      generating the __bug_table entry.
      [randy.dunlap@oracle.com: Handle BUG=n, GENERIC_BUG=n to prevent build errors]
      [bunk@stusta.de: include/linux/bug.h must always #include <linux/module.h]
      Signed-off-by: 's avatarJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: 's avatarAdrian Bunk <bunk@stusta.de>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>