summaryrefslogtreecommitdiff
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorSteven Rostedt <rostedt@goodmis.org>2016-03-18 00:21:12 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2016-03-18 01:09:34 +0300
commitdfbf2897d00499f94cd53a9806e697392cbfe6a3 (patch)
tree8924f5944414db64bed0ec43f861b17ce91afcbc /MAINTAINERS
parentc60f169202c7643991a8b4bfeea60e06843d5b5a (diff)
downloadlinux-dfbf2897d00499f94cd53a9806e697392cbfe6a3.tar.xz
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