diff options
author | Peter Zijlstra <peterz@infradead.org> | 2013-11-19 16:42:47 +0100 |
---|---|---|
committer | Ingo Molnar <mingo@kernel.org> | 2013-11-19 17:07:00 +0100 |
commit | f1a83e652bedef88d6d77d3dc58250e08e7062bd (patch) | |
tree | 8ab638d983ed32cde49b28db44a1e4d9df98ede6 /mm/failslab.c | |
parent | 9dd1220114e00d8ec5cdc20085bbe198b21e1985 (diff) | |
download | linux-f1a83e652bedef88d6d77d3dc58250e08e7062bd.tar.gz linux-f1a83e652bedef88d6d77d3dc58250e08e7062bd.tar.bz2 linux-f1a83e652bedef88d6d77d3dc58250e08e7062bd.zip |
lockdep: Correctly annotate hardirq context in irq_exit()
There was a reported deadlock on -rt which lockdep didn't report.
It turns out that in irq_exit() we tell lockdep that the hardirq
context ends and then do all kinds of locking afterwards.
To fix it, move trace_hardirq_exit() to the very end of irq_exit(), this
ensures all locking in tick_irq_exit() and rcu_irq_exit() are properly
recorded as happening from hardirq context.
This however leads to the 'fun' little problem of running softirqs
while in hardirq context. To cure this make the softirq code a little
more complex (in the CONFIG_TRACE_IRQFLAGS case).
Due to stack swizzling arch dependent trickery we cannot pass an
argument to __do_softirq() to tell it if it was done from hardirq
context or not; so use a side-band argument.
When we do __do_softirq() from hardirq context, 'atomically' flip to
softirq context and back, so that no locking goes without being in
either hard- or soft-irq context.
I didn't find any new problems in mainline using this patch, but it
did show the -rt problem.
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/n/tip-dgwc5cdksbn0jk09vbmcc9sa@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'mm/failslab.c')
0 files changed, 0 insertions, 0 deletions