1. 17 Mar, 2016 2 commits
  2. 01 Mar, 2016 1 commit
    • Arnd Bergmann's avatar
      asm-generic: default BUG_ON(x) to if(x)BUG() · 3c047057
      Arnd Bergmann authored
      When CONFIG_BUG is disabled, BUG_ON() will only evaluate the condition,
      but will not actually stop the current thread. GCC warns about a couple
      of BUG_ON() users where this actually leads to further undefined
      include/linux/ceph/osdmap.h: In function 'ceph_can_shift_osds':
      include/linux/ceph/osdmap.h:54:1: warning: control reaches end of non-void function
      fs/ext4/inode.c: In function 'ext4_map_blocks':
      fs/ext4/inode.c:548:5: warning: 'retval' may be used uninitialized in this function
      drivers/mfd/db8500-prcmu.c: In function 'prcmu_config_clkout':
      drivers/mfd/db8500-prcmu.c:762:10: warning: 'div_mask' may be used uninitialized in this function
      drivers/mfd/db8500-prcmu.c:769:13: warning: 'mask' may be used uninitialized in this function
      drivers/mfd/db8500-prcmu.c:757:7: warning: 'bits' may be used uninitialized in this function
      drivers/tty/serial/8250/8250_core.c: In function 'univ8250_release_irq':
      drivers/tty/serial/8250/8250_core.c:252:18: warning: 'i' may be used uninitialized in this function
      drivers/tty/serial/8250/8250_core.c:235:19: note: 'i' was declared here
      There is an obvious conflict of interest here: on the one hand, someone
      who disables CONFIG_BUG() will want the kernel to be as small as possible
      and doesn't care about printing error messages to a console that nobody
      looks at. On the other hand, running into a BUG_ON() condition means that
      something has gone wrong, and we probably want to also stop doing things
      that might cause data corruption.
      This patch picks the second choice, and changes the NOP to BUG(), which
      normally stops the execution of the current thread in some form (endless
      loop or a trap). This follows the logic we applied in a4b5d580 ("bug:
      Make BUG() always stop the machine").
      For ARM multi_v7_defconfig, the size slightly increases:
      section		CONFIG_BUG=y	CONFIG_BUG=n	CONFIG_BUG=n+patch
        .text            8320248   |     8180944   |     8207688
        .rodata          3633720   |     3567144   |     3570648
        __bug_table        32508   |         ---   |         ---
        __modver             692   |        1584   |        2176
        .init.text        558132   |      548300   |      550088
        .exit.text         12380   |       12256   |       12380
        .data            1016672   |     1016064   |     1016128
        Total           14622556   |    14374510   |    14407326
      So instead of saving 1.70% of the total image size, we only save 1.48%
      by turning off CONFIG_BUG, but in return we can ensure that we don't run
      into cases of uninitialized variable or return code uses when something
      bad happens. Aside from that, we significantly reduce the number of
      warnings in randconfig builds, which makes it easier to fix the warnings
      about other problems.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
  3. 07 Apr, 2014 4 commits
  4. 25 Jun, 2012 1 commit
    • Paul Mundt's avatar
      bug.h: Fix up CONFIG_BUG=n implicit function declarations. · 09682c1d
      Paul Mundt authored
      Commit 2603efa3 ("bug.h: Fix up powerpc build regression") corrected
      the powerpc build case and extended the __ASSEMBLY__ guards, but it also
      got caught in pre-processor hell accidentally matching the else case of
      CONFIG_BUG resulting in the BUG disabled case tripping up on
      It's not possible to __ASSEMBLY__ guard the entire file as architecture
      code needs to get at the BUGFLAG_WARNING definition in the GENERIC_BUG
      case, but the rest of the CONFIG_BUG=y/n case needs to be guarded.
      Rather than littering endless __ASSEMBLY__ checks in each of the if/else
      cases we just move the BUGFLAG definitions up under their own
      GENERIC_BUG test and then shove everything else under one big
      __ASSEMBLY__ guard.
      Build tested on all of x86 CONFIG_BUG=y, CONFIG_BUG=n, powerpc (due to
      it's dependence on BUGFLAG definitions in assembly code), and sh (due to
      not bringing in linux/kernel.h to satisfy the taint flag definitions used
      by the generic bug code).
      Hopefully that's the end of the corner cases and I can abstain from ever
      having to touch this infernal header ever again.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Tested-by: default avatarFengguang Wu <wfg@linux.intel.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 18 Jun, 2012 1 commit
    • Paul Mundt's avatar
      bug.h: Fix up powerpc build regression. · 2603efa3
      Paul Mundt authored
      The asm-generic/bug.h __ASSEMBLY__ guarding is completely bogus, which
      tripped up the powerpc build when the kernel.h include was added:
      	In file included from include/asm-generic/bug.h:5:0,
      			 from arch/powerpc/include/asm/bug.h:127,
      			 from arch/powerpc/kernel/head_64.S:31:
      	include/linux/kernel.h:44:0: warning: "ALIGN" redefined [enabled by default]
      	include/linux/linkage.h:57:0: note: this is the location of the previous definition
      	include/linux/sysinfo.h: Assembler messages:
      	include/linux/sysinfo.h:7: Error: Unrecognized opcode: `struct'
      	include/linux/sysinfo.h:8: Error: Unrecognized opcode: `__kernel_long_t'
      Moving the __ASSEMBLY__ guard up and stashing the kernel.h include under
      it fixes this up, as well as covering the case the original fix was
      attempting to handle.
      Tested-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  6. 10 Jun, 2012 1 commit
  7. 23 Mar, 2012 1 commit
  8. 31 Oct, 2011 1 commit
  9. 26 May, 2011 1 commit
  10. 24 May, 2011 1 commit
  11. 23 May, 2011 1 commit
  12. 28 Mar, 2011 1 commit
    • Steven Rostedt's avatar
      WARN_ON_SMP(): Add comment to explain ({0;}) · ccd0d44f
      Steven Rostedt authored
      The define to use ({0;}) for the !CONFIG_SMP case of WARN_ON_SMP()
      can be confusing. As the WARN_ON_SMP() needs to be a nop when
      CONFIG_SMP is not set, including all its parameters must not be
      evaluated, and that it must work as both a stand alone statement
      and inside an if condition, we define it to a funky ({0;}).
      A simple "0" will not work as it causes gcc to give the warning that
      the statement has no effect.
      As this strange definition has raised a few eyebrows from some
      major kernel developers, it is wise to document why we create such
      a work of art.
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
  13. 25 Mar, 2011 1 commit
  14. 19 May, 2010 1 commit
  15. 15 Dec, 2009 1 commit
  16. 06 May, 2009 1 commit
  17. 15 Apr, 2009 1 commit
  18. 06 Jan, 2009 1 commit
  19. 16 Dec, 2008 1 commit
  20. 28 Nov, 2008 1 commit
  21. 20 Oct, 2008 1 commit
  22. 16 Oct, 2008 1 commit
  23. 16 Sep, 2008 1 commit
  24. 08 Sep, 2008 1 commit
  25. 25 Jul, 2008 2 commits
  26. 30 Jan, 2008 2 commits
  27. 31 Jul, 2007 1 commit
    • Linus Torvalds's avatar
      Fix WARN_ON() on bitfield ops · 8d4fbcfb
      Linus Torvalds authored
      Alexey Dobriyan noticed that the new WARN_ON() semantics that were
      introduced by commit 684f9783 (to also
      return the value to be warned on) didn't compile when given a bitfield,
      because the typeof doesn't work for bitfields.
      So instead of the typeof trick, use an "int" variable together with a
      "!!(x)" expression, as suggested by Al Viro.
      To make matters more interesting, Paul Mackerras points out that that is
      sub-optimal on Power, but the old asm-coded comparison seems to be buggy
      anyway on 32-bit Power if the conditional was 64-bit, so I think there
      are more problems there.
      Regardless, the new WARN_ON() semantics may have been a bad idea.  But
      this at least avoids the more serious complications.
      Cc: Alexey Dobriyan <adobriyan@sw.ru>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  28. 17 Jul, 2007 1 commit
  29. 24 May, 2007 1 commit
  30. 30 Dec, 2006 1 commit
    • Ingo Molnar's avatar
      [PATCH] change WARN_ON back to "BUG: at ..." · 52e88f5d
      Ingo Molnar authored
      WARN_ON() ever triggering is a kernel bug.  Do not try to paper over this
      fact by suggesting to the user that this is 'only' a warning, as the
      following recent commit does:
        commit 30e25b71
        Author: Jeremy Fitzhardinge <jeremy@goop.org>
        Date:   Fri Dec 8 02:36:24 2006 -0800
          [PATCH] Fix generic WARN_ON message
          A warning is a warning, not a BUG.
      ( it might make sense to rename BUG() to CRASH() and BUG_ON() to
        CRASH_ON(), but that does not change the fact that WARN_ON()
        signals a kernel bug. )
      i and others objected to this change during lkml review:
      still the change slipped upstream - grumble :)
      Also, use the standard "BUG: " format to make it easier to grep logs and
      to make it easier to google for kernel bugs.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  31. 08 Dec, 2006 2 commits
    • Jeremy Fitzhardinge's avatar
      [PATCH] Fix generic WARN_ON message · 30e25b71
      Jeremy Fitzhardinge authored
      A warning is a warning, not a BUG.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • 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: default 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: default avatarAdrian Bunk <bunk@stusta.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  32. 20 Oct, 2006 1 commit
    • Ralf Baechle's avatar
      [PATCH] Fix warnings for WARN_ON if CONFIG_BUG is disabled · 8c7c7c9b
      Ralf Baechle authored
      In most cases the return value of WARN_ON() is ignored.  If the generic
      definition for the !CONFIG_BUG case is used this will result in a warning:
        CC      kernel/sched.o
      In file included from include/linux/bio.h:25,
                       from include/linux/blkdev.h:14,
                       from kernel/sched.c:39:
      include/linux/ioprio.h: In function ‘task_ioprio’:
      include/linux/ioprio.h:50: warning: statement with no effect
      kernel/sched.c: In function ‘context_switch’:
      kernel/sched.c:1834: warning: statement with no effect
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  33. 06 Oct, 2006 1 commit
    • Andrew Morton's avatar
      [PATCH] Fix WARN_ON / WARN_ON_ONCE regression · d69a8922
      Andrew Morton authored
      Tim and Ananiev report that the recent WARN_ON_ONCE changes cause increased
      cache misses with the tbench workload.  Apparently due to the access to the
      newly-added static variable.
      Rearrange the code so that we don't touch that variable unless the warning is
      going to trigger.
      Also rework the logic so that the static variable starts out at zero, so we
      can move it into bss.
      It would seem logical to mark the static variable as __read_mostly too.  But
      it would be wrong, because that would put it back into the vmlinux image, and
      the kernel will never read from this variable in normal operation anyway.
      Unless the compiler or hardware go and do some prefetching on us?
      For some reason this patch shrinks softirq.o text by 40 bytes.
      Cc: Tim Chen <tim.c.chen@intel.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "Ananiev, Leonid I" <leonid.i.ananiev@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>