30 May, 2018
1 commit
-
[ Upstream commit 173a3efd3edb2ef6ef07471397c5f542a360e9c1 ]
Looking at functions with large stack frames across all architectures
led me discovering that BUG() suffers from the same problem as
fortify_panic(), which I've added a workaround for already.In short, variables that go out of scope by calling a noreturn function
or __builtin_unreachable() keep using stack space in functions
afterwards.A workaround that was identified is to insert an empty assembler
statement just before calling the function that doesn't return. I'm
adding a macro "barrier_before_unreachable()" to document this, and
insert calls to that in all instances of BUG() that currently suffer
from this problem.The files that saw the largest change from this had these frame sizes
before, and much less with my patch:fs/ext4/inode.c:82:1: warning: the frame size of 1672 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/namei.c:434:1: warning: the frame size of 904 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/super.c:2279:1: warning: the frame size of 1160 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/xattr.c:146:1: warning: the frame size of 1168 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/f2fs/inode.c:152:1: warning: the frame size of 1424 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_core.c:1195:1: warning: the frame size of 1068 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_core.c:395:1: warning: the frame size of 1084 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_ftp.c:298:1: warning: the frame size of 928 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_ftp.c:418:1: warning: the frame size of 908 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_lblcr.c:718:1: warning: the frame size of 960 bytes is larger than 800 bytes [-Wframe-larger-than=]
drivers/net/xen-netback/netback.c:1500:1: warning: the frame size of 1088 bytes is larger than 800 bytes [-Wframe-larger-than=]In case of ARC and CRIS, it turns out that the BUG() implementation
actually does return (or at least the compiler thinks it does),
resulting in lots of warnings about uninitialized variable use and
leaving noreturn functions, such as:block/cfq-iosched.c: In function 'cfq_async_queue_prio':
block/cfq-iosched.c:3804:1: error: control reaches end of non-void function [-Werror=return-type]
include/linux/dmaengine.h: In function 'dma_maxpq':
include/linux/dmaengine.h:1123:1: error: control reaches end of non-void function [-Werror=return-type]This makes them call __builtin_trap() instead, which should normally
dump the stack and kill the current process, like some of the other
architectures already do.I tried adding barrier_before_unreachable() to panic() and
fortify_panic() as well, but that had very little effect, so I'm not
submitting that patch.Vineet said:
: For ARC, it is double win.
:
: 1. Fixes 3 -Wreturn-type warnings
:
: | ../net/core/ethtool.c:311:1: warning: control reaches end of non-void function
: [-Wreturn-type]
: | ../kernel/sched/core.c:3246:1: warning: control reaches end of non-void function
: [-Wreturn-type]
: | ../include/linux/sunrpc/svc_xprt.h:180:1: warning: control reaches end of
: non-void function [-Wreturn-type]
:
: 2. bloat-o-meter reports code size improvements as gcc elides the
: generated code for stack return.Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: http://lkml.kernel.org/r/20171219114112.939391-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Acked-by: Vineet Gupta [arch/arc]
Tested-by: Vineet Gupta [arch/arc]
Cc: Mikael Starvik
Cc: Jesper Nilsson
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Geert Uytterhoeven
Cc: "David S. Miller"
Cc: Christopher Li
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Josh Poimboeuf
Cc: Will Deacon
Cc: "Steven Rostedt (VMware)"
Cc: Mark Rutland
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
11 Jul, 2017
1 commit
-
This series of patches splits BUILD_BUG related macros out of
"include/linux/bug.h" into new file "include/linux/build_bug.h" (patch
5), and changes the pointer type checking in the `container_of()` macro
to deal with pointers of array type better (patch 6). Patches 1 to 4
are prerequisites.Patches 2, 3, 4, and 5 have been inserted since the previous version of
this patch series. Patch 6 here corresponds to v3 and v4's patch 2.Patch 1 was a prerequisite in v3 of this series to avoid a lot of
warnings when was included by . That is
no longer relevant for v5 of the series, but I left it in because it was
acked by a Arnd Bergmann and Michal Nazarewicz.Patches 2, 3, and 4 are some checkpatch clean-ups on
"include/linux/bug.h" before splitting out the BUILD_BUG stuff in patch
5.Patch 5 splits the BUILD_BUG related macros out of "include/linux/bug.h"
into new file "include/linux/build_bug.h" because including
in "include/linux/kernel.h" would result in build failures
due to circular dependencies.Patch 6 changes the pointer type checking by `container_of()` to avoid
some incompatible pointer warnings when the dereferenced pointer has
array type.1) asm-generic/bug.h: declare struct pt_regs; before function prototype
2) linux/bug.h: correct formatting of block comment
3) linux/bug.h: correct "(foo*)" should be "(foo *)"
4) linux/bug.h: correct "space required before that '-'"
5) bug: split BUILD_BUG stuff out into
6) kernel.h: handle pointers to arrays better in container_of()This patch (of 6):
The declaration of `__warn()` has `struct pt_regs *regs` as one of its
parameters. This can result in compiler warnings if `struct regs` is not
already declared. Add an empty declaration of `struct pt_regs` to avoid
the warnings.Link: http://lkml.kernel.org/r/20170525120316.24473-2-abbotti@mev.co.uk
Signed-off-by: Ian Abbott
Acked-by: Arnd Bergmann
Acked-by: Michal Nazarewicz
Cc: Arnd Bergmann
Cc: Kees Cook
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Apr, 2017
1 commit
-
Dan reported that his static checking complains about BUGFLAG_WARNING
being set on both sides of the bitwise-or, it figures that that might've
been an unintentional mistake.Since there are no architectures that implement __WARN_TAINT() (I
converted them all to implement __WARN_FLAGS()), and all __WARN_FLAGS()
implementations already set BUGFLAG_WARNING, we can remove the bit from
BUGFLAG_TAINT() and make Dan's checker happy.Reported-by: Dan Carpenter
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20170410084939.4bwhrvpmauwfzauq@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
30 Mar, 2017
1 commit
-
Josh suggested moving the _ONCE logic inside the trap handler, using a
bit in the bug_entry::flags field, avoiding the need for the extra
variable.Sadly this only works for WARN_ON_ONCE(), since the others have
printk() statements prior to triggering the trap.Still, this saves a fair amount of text and some data:
text data filename
10682460 4530992 defconfig-build/vmlinux.orig
10665111 4530096 defconfig-build/vmlinux.patchedSuggested-by: Josh Poimboeuf
Signed-off-by: Peter Zijlstra (Intel)
Cc: Andy Lutomirski
Cc: Arnd Bergmann
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar
25 Mar, 2016
1 commit
-
Pull asm-generic updates from Arnd Bergmann:
"There are only three patches this time, most other changes to files in
include/asm-generic tend to go through the tree of whoever depends on
the change.Two patches are cleanups for stuff that is no longer needed, the main
change is to adapt the generic version of BUG_ON() for CONFIG_BUG=n to
make it behave consistently with BUG().This avoids undefined behavior along with a number of warnings about
that undefined behavior in randconfig builds when we keep going on
after hitting a BUG_ON()"* tag 'asm-generic-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
asm-generic: remove old nonatomic-io wrapper files
asm-generic: default BUG_ON(x) to if(x)BUG()
asm-generic: page.h: Remove useless get_user_page and free_user_page
18 Mar, 2016
2 commits
-
The traceoff_on_warning option doesn't have any effect on s390, powerpc,
arm64, parisc, and sh because there are two different types of WARN
implementations:1) The above mentioned architectures treat WARN() as a special case of a
BUG() exception. They handle warnings in report_bug() in lib/bug.c.2) All other architectures just call warn_slowpath_*() directly. Their
warnings are handled in warn_slowpath_common() in kernel/panic.c.Support traceoff_on_warning on all architectures and prevent any future
divergence by using a single common function to emit the warning.Also remove the '()' from '%pS()', because the parentheses look funky:
[ 45.607629] WARNING: at /root/warn_mod/warn_mod.c:17 .init_dummy+0x20/0x40 [warn_mod]()
Reported-by: Chunyu Hu
Signed-off-by: Josh Poimboeuf
Acked-by: Heiko Carstens
Tested-by: Prarit Bhargava
Acked-by: Prarit Bhargava
Acked-by: Steven Rostedt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This has hit me a couple of times already. I would be debugging code
and the system would simply hang and then reboot. Finally, I found that
the problem was caused by WARN_ON_ONCE() and friends.The macro WARN_ON_ONCE(condition) is defined as:
static bool __section(.data.unlikely) __warned;
int __ret_warn_once = !!(condition);if (unlikely(__ret_warn_once))
if (WARN_ON(!__warned))
__warned = true;unlikely(__ret_warn_once);
Which looks great and all. But what I have hit, is an issue when
WARN_ON() itself hits the same WARN_ON_ONCE() code. Because, the
variable __warned is not yet set. Then it too calls WARN_ON() and that
triggers the warning again. It keeps doing this until the stack is
overflowed and the system crashes.By setting __warned first before calling WARN_ON() makes the original
WARN_ON_ONCE() really only warn once, and not an infinite amount of
times if the WARN_ON() also triggers the warning.Signed-off-by: Steven Rostedt
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
02 Mar, 2016
1 commit
-
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
behavior: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 hereThere 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 a4b5d580e078 ("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 | 14407326So 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: Arnd Bergmann
08 Apr, 2014
4 commits
-
When !CONFIG_BUG and !HAVE_ARCH_BUG, define the generic BUG() as an
infinite loop rather than a no-op. This avoids undefined behavior if
execution ever actually reaches BUG(), and avoids warnings about code
after BUG() (such as on non-void functions calling BUG() and then not
returning).bloat-o-meter results:
add/remove: 0/0 grow/shrink: 43/10 up/down: 235/-98 (137)
function old new delta
umount_collect 119 138 +19
notify_change 306 324 +18
xstate_enable_boot_cpu 252 269 +17
kunmap 54 70 +16
balloon_page_dequeue 112 126 +14
mm_take_all_locks 223 233 +10
list_lru_walk_node 143 152 +9
vma_adjust 1059 1067 +8
pcpu_setup_first_chunk 1130 1138 +8
mm_drop_all_locks 143 151 +8
ns_capable 55 62 +7
anon_transport_class_unregister 8 15 +7
srcu_init_notifier_head 35 41 +6
shrink_dcache_for_umount 174 180 +6
kunmap_high 99 105 +6
end_page_writeback 43 49 +6
do_exit 1339 1345 +6
__kfifo_dma_out_prepare_r 86 92 +6
__kfifo_dma_in_prepare_r 90 96 +6
fixup_user_fault 120 125 +5
repair_env_string 73 77 +4
read_cache_pages_invalidate_page 56 60 +4
isolate_lru_pages.isra 142 146 +4
do_notify_parent_cldstop 255 259 +4
cpu_init 370 374 +4
utimes_common 270 272 +2
tasklet_hi_action 91 93 +2
tasklet_action 91 93 +2
set_pte_vaddr 46 48 +2
find_get_pages_tag 202 204 +2
early_iounmap 185 187 +2
__native_set_fixmap 36 38 +2
__get_user_pages 822 824 +2
__early_ioremap 299 301 +2
yield_task_stop 1 2 +1
tick_resume 37 38 +1
switched_to_stop 1 2 +1
switched_to_idle 1 2 +1
prio_changed_stop 1 2 +1
prio_changed_idle 1 2 +1
pm_qos_power_read 111 112 +1
arch_cpu_idle_dead 1 2 +1
__insert_vmap_area 140 141 +1
sys_renameat 614 612 -2
mm_fault_error 297 295 -2
SyS_renameat 614 612 -2
sys_linkat 416 413 -3
SyS_linkat 416 413 -3
chmod_common 129 122 -7
proc_cap_handler 240 225 -15
__schedule 849 831 -18
sys_madvise 1077 1054 -23
SyS_madvise 1077 1054 -23Signed-off-by: Josh Triplett
Reported-by: Arnd Bergmann
Acked-by: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The stub version of WARN for !CONFIG_BUG completely ignored its format
string and subsequent arguments; make it check them instead, using
no_printk.Signed-off-by: Josh Triplett
Reported-by: Arnd Bergmann
Acked-by: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Signed-off-by: Josh Triplett
Reported-by: Randy Dunlap
Acked-by: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
condition argument; however, WARN_ON_ONCE and family still have conditions
and a boolean to detect one-time invocation, even though the warning
they'd emit doesn't exist. Make the existing definitions conditional on
CONFIG_BUG, and add definitions for !CONFIG_BUG that map to the
passthrough versions of WARN and WARN_ON.This saves 4.4k on a minimized configuration (smaller than allnoconfig),
and 20.6k with defconfig plus CONFIG_BUG=n.Signed-off-by: Josh Triplett
Acked-by: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Jun, 2012
1 commit
-
Commit 2603efa31a03 ("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
-Werror=implicit-function-declaration.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: Fengguang Wu
Tested-by: Fengguang Wu
Acked-by: Randy Dunlap
Cc: Arnd Bergmann
Signed-off-by: Paul Mundt
Signed-off-by: Linus Torvalds
19 Jun, 2012
1 commit
-
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: Stephen Rothwell
Acked-by: Arnd Bergmann
Signed-off-by: Paul Mundt
Signed-off-by: Linus Torvalds
11 Jun, 2012
1 commit
-
asm-generic/bug.h uses taint flags that are only defined in
linux/kernel.h, resulting in build failures on platforms that
don't include linux/kernel.h some other way:arch/sh/include/asm/thread_info.h:172:2: error: 'TAINT_WARN' undeclared (first use in this function)
Caused by commit edd63a2763bd ("set_restore_sigmask() is never called
without SIGPENDING (and never should be)").Reported-by: Stephen Rothwell
Cc: Al Viro
Signed-off-by: Paul Mundt
24 Mar, 2012
1 commit
-
Due to the alignment of following variables, these typically consume
more than just the single byte that 'bool' requires, and as there are a
few hundred instances, the cache pollution (not so much the waste of
memory) sums up. Put these variables into their own section, outside of
any half way frequently used memory range.Do the same also to the __warned variable of rcu_lockdep_assert().
(Don't, however, include the ones used by printk_once() and alike, as
they can potentially be hot.)Signed-off-by: Jan Beulich
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Nov, 2011
1 commit
-
Standardize the style for compiler based printf format verification.
Standardized the location of __printf too.Done via script and a little typing.
$ grep -rPl --include=*.[ch] -w "__attribute__" * | \
grep -vP "^(tools|scripts|include/linux/compiler-gcc.h)" | \
xargs perl -n -i -e 'local $/; while (<>) { s/\b__attribute__\s*\(\s*\(\s*format\s*\(\s*printf\s*,\s*(.+)\s*,\s*(.+)\s*\)\s*\)\s*\)/__printf($1, $2)/g ; print; }'[akpm@linux-foundation.org: revert arch bits]
Signed-off-by: Joe Perches
Cc: "Kirill A. Shutemov"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 May, 2011
1 commit
-
As reported by Ingo Molnar, we still have configuration combinations
where use of the WARN_RATELIMIT interfaces break the build because
dependencies don't get met.Instead of going down the long road of trying to make it so that
ratelimit.h can get included by kernel.h or asm-generic/bug.h,
just move the interface into ratelimit.h and make users have
to include that.Reported-by: Ingo Molnar
Signed-off-by: David S. Miller
Acked-by: Randy Dunlap
25 May, 2011
1 commit
-
Based upon an email by Joe Perches.
Reported-by: Randy Dunlap
Signed-off-by: David S. Miller
Acked-by: Randy Dunlap
24 May, 2011
1 commit
-
Add a generic mechanism to ratelimit WARN(foo, fmt, ...) messages
using a hidden per call site static struct ratelimit_state.Also add an __WARN_RATELIMIT variant to be able to use a specific
struct ratelimit_state.Signed-off-by: Joe Perches
Signed-off-by: David S. Miller
28 Mar, 2011
1 commit
-
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
Cc: Alexey Dobriyan
Signed-off-by: Steven Rostedt
25 Mar, 2011
1 commit
-
Both WARN_ON() and WARN_ON_SMP() should be able to be used in
an if statement.if (WARN_ON_SMP(foo)) { ... }
Because WARN_ON_SMP() is defined as a do { } while (0) on UP,
it can not be used this way.Convert it to the same form that WARN_ON() is, even when
CONFIG_SMP is off.Signed-off-by: Steven Rostedt
Acked-by: Thomas Gleixner
Acked-by: Peter Zijlstra
Acked-by: Darren Hart
Cc: Lai Jiangshan
Cc: Linus Torvalds
Cc: Andrew Morton
LKML-Reference:
Signed-off-by: Ingo Molnar
19 May, 2010
1 commit
-
WARN() is used in some places to report firmware or hardware bugs that
are then worked-around. These bugs do not affect the stability of the
kernel and should not set the flag for TAINT_WARN. To allow for this,
add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint number
as argument.Architectures that implement warnings using trap instructions instead
of calls to warn_slowpath_*() now implement __WARN_TAINT(taint)
instead of __WARN().Signed-off-by: Ben Hutchings
Acked-by: Helge Deller
Tested-by: Paul Mundt
Signed-off-by: David Woodhouse
16 Dec, 2009
1 commit
-
Commit 70867453092297be9afb2249e712a1f960ec0a09 ("printk_once(): use bool
for boolean flag") changed printk_once() to use bool instead of int for
its guard variable. Do the same change to WARN_ONCE() and WARN_ON_ONCE(),
for the same reasons.This resulted in a reduction of 1462 bytes on a x86-64 defconfig:
text data bss dec hex filename
8101271 1207116 992764 10301151 9d2edf vmlinux.before
8100553 1207148 991988 10299689 9d2929 vmlinux.afterSigned-off-by: Cesar Eduardo Barros
Cc: Roland Dreier
Cc: Daniel Walker
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 May, 2009
1 commit
-
When building with gcc 3.2 I get thousands of warnings such as
include/linux/gfp.h: In function `allocflags_to_migratetype':
include/linux/gfp.h:105: warning: null format stringdue to passing a NULL format string to warn_slowpath() in
#define __WARN() warn_slowpath(__FILE__, __LINE__, NULL)
Split this case out into a separate call. This also shrinks the kernel
slightly:text data bss dec hex filename
4802274 707668 712704 6222646 5ef336 vmlinux
text data bss dec hex filename
4799027 703572 712704 6215303 5ed687 vmlinuxdue to removeing one argument from the commonly-called __WARN().
[akpm@linux-foundation.org: reduce scope of `empty']
Acked-by: Jesper Nilsson
Acked-by: Johannes Weiner
Acked-by: Arjan van de Ven
Signed-off-by: Andi Kleen
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
16 Apr, 2009
1 commit
-
The default CONFIG_BUG=n version of BUG() should incorporate an empty a
do...while statement to avoid compilation weirdness.Signed-off-by: David Howells
Signed-off-by: Linus Torvalds
07 Jan, 2009
1 commit
-
Provide some basic advice about when to use BUG()/BUG_ON(): never, unless
there's really no better option.This matches my understanding of the standard policy ... which seems not
to be written down so far, outside of LKML messages that I haven't
bookmarked.Signed-off-by: David Brownell
Cc: Hans Verkuil
Cc: Ingo Molnar
Cc: Arjan van de Ven
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Dec, 2008
1 commit
-
* 'core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (63 commits)
stacktrace: provide save_stack_trace_tsk() weak alias
rcu: provide RCU options on non-preempt architectures too
printk: fix discarding message when recursion_bug
futex: clean up futex_(un)lock_pi fault handling
"Tree RCU": scalable classic RCU implementation
futex: rename field in futex_q to clarify single waiter semantics
x86/swiotlb: add default swiotlb_arch_range_needs_mapping
x86/swiotlb: add default physbus conversion
x86: unify pci iommu setup and allow swiotlb to compile for 32 bit
x86: add swiotlb allocation functions
swiotlb: consolidate swiotlb info message printing
swiotlb: support bouncing of HighMem pages
swiotlb: factor out copy to/from device
swiotlb: add arch hook to force mapping
swiotlb: allow architectures to override physbusphys conversions
swiotlb: add comment where we handle the overflow of a dma mask on 32 bit
rcu: fix rcutorture behavior during reboot
resources: skip sanity check of busy resources
swiotlb: move some definitions to header
swiotlb: allow architectures to override swiotlb pool allocation
...Fix up trivial conflicts in
arch/x86/kernel/Makefile
arch/x86/mm/init_32.c
include/linux/hardirq.h
as per Ingo's suggestions.
17 Dec, 2008
1 commit
-
Impact: reduce bug table size
This allows reducing the bug table size by half. Perhaps there are
other 64-bit architectures that could also make use of this.Signed-off-by: Jan Beulich
Signed-off-by: Ingo Molnar
29 Nov, 2008
1 commit
-
Impact: cleanup, eliminate code
now that warn_on_slowpath() uses warn_slowpath(...,NULL), we can
eliminate warn_on_slowpath() altogether and use warn_slowpath().Signed-off-by: Ingo Molnar
21 Oct, 2008
1 commit
-
powerpc doesn't use the generic WARN_ON infrastructure. The newly
introduced WARN() as a result didn't print the message, this patch adds
the printk for this specific case.Signed-off-by: Arjan van de Ven
Signed-off-by: Linus Torvalds
17 Oct, 2008
1 commit
-
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Sep, 2008
1 commit
-
this patch turns the netdev timeout WARN_ON_ONCE() into a WARN_ONCE(),
so that the device and driver names are inside the warning message.
This helps automated tools like kerneloops.org to collect the data
and do statistics, as well as making it more likely that humans
cut-n-paste the important message as part of a bugreport.Signed-off-by: Arjan van de Ven
Signed-off-by: Linus Torvalds
26 Jul, 2008
2 commits
-
All ratelimit user use same jiffies and burst params, so some messages
(callbacks) will be lost.For example:
a call printk_ratelimit(5 * HZ, 1)
b call printk_ratelimit(5 * HZ, 1) before the 5*HZ timeout of a, then b will
will be supressed.- rewrite __ratelimit, and use a ratelimit_state as parameter. Thanks for
hints from andrew.- Add WARN_ON_RATELIMIT, update rcupreempt.h
- remove __printk_ratelimit
- use __ratelimit in net_ratelimit
Signed-off-by: Dave Young
Cc: "David S. Miller"
Cc: "Paul E. McKenney"
Cc: Dave Young
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add a WARN() macro that acts like WARN_ON(), with the added feature that it
takes a printk like argument that is printed as part of the warning message.[akpm@linux-foundation.org: fix printk arguments]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Arjan van de Ven
Cc: Greg KH
Cc: Jiri Slaby
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Jan, 2008
2 commits
-
A quick grep shows that there are currently 1145 instances of WARN_ON
in the kernel. Currently, WARN_ON is pretty much entirely inlined,
which makes it hard to enhance it without growing the size of the kernel
(and getting Andrew unhappy).This patch build on top of Olof's patch that introduces __WARN,
and places the slowpath out of line. It also uses Ingo's suggestion
to not use __FUNCTION__ but to use kallsyms to do the lookup;
this saves a ton of extra space since gcc doesn't need to store the function
string twice now:3936367 833603 624736 5394706 525112 vmlinux.before
3917508 833603 624736 5375847 520767 vmlinux-slowpath15Kb savings...
Signed-off-by: Arjan van de Ven
CC: Andrew Morton
CC: Olof Johansson
Acked-by: Matt Meckall
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.Signed-off-by: Olof Johansson
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
01 Aug, 2007
1 commit
-
Alexey Dobriyan noticed that the new WARN_ON() semantics that were
introduced by commit 684f978347deb42d180373ac4c427f82ef963171 (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
Cc: Herbert Xu
Cc: Paul Mackerras
Cc: Al Viro
Cc: Ingo Molnar
Cc: Andrew Morton
Signed-off-by: Linus Torvalds
18 Jul, 2007
1 commit
-
sparse now warns if one compares pointers with integers. However, there are
false positives, like:fs/filesystems.c:72:2: warning: Using plain integer as NULL pointer
Every time BUG_ON(ptr) is used, ptr is checked against integer zero. Avoid
that and save ~70 false positives from allyesconfig run.mentioned by Al.
Signed-off-by: Alexey Dobriyan
Acked-by: Al Viro
Acked-by: Josh Triplett
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
