diff options
author | Steven Rostedt <rostedt@goodmis.org> | 2016-03-17 14:21:12 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2016-03-17 15:09:34 -0700 |
commit | dfbf2897d00499f94cd53a9806e697392cbfe6a3 (patch) | |
tree | 8924f5944414db64bed0ec43f861b17ce91afcbc /MAINTAINERS | |
parent | c60f169202c7643991a8b4bfeea60e06843d5b5a (diff) | |
download | linux-dfbf2897d00499f94cd53a9806e697392cbfe6a3.tar.gz linux-dfbf2897d00499f94cd53a9806e697392cbfe6a3.tar.bz2 linux-dfbf2897d00499f94cd53a9806e697392cbfe6a3.zip |
bug: set warn variable before calling WARN()
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 <rostedt@goodmis.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions