Messages in this thread | | | Date | Wed, 2 Dec 2020 13:27:34 +0100 | From | Peter Zijlstra <> | Subject | Re: [GIT pull] locking/urgent for v5.10-rc6 |
| |
On Wed, Dec 02, 2020 at 11:56:49AM +0100, Heiko Carstens wrote: > From 7bd86fb3eb039a4163281472ca79b9158e726526 Mon Sep 17 00:00:00 2001 > From: Heiko Carstens <hca@linux.ibm.com> > Date: Wed, 2 Dec 2020 11:46:01 +0100 > Subject: [PATCH] s390: fix irq state tracing > > With commit 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs > tracing") common code calls arch_cpu_idle() with a lockdep state that > tells irqs are on. > > This doesn't work very well for s390: psw_idle() will enable interrupts > to wait for an interrupt. As soon as an interrupt occurs the interrupt > handler will verify if the old context was psw_idle(). If that is the > case the interrupt enablement bits in the old program status word will > be cleared. > > A subsequent test in both the external as well as the io interrupt > handler checks if in the old context interrupts were enabled. Due to > the above patching of the old program status word it is assumed the > old context had interrupts disabled, and therefore a call to > TRACE_IRQS_OFF (aka trace_hardirqs_off_caller) is skipped. Which in > turn makes lockdep incorrectly "think" that interrupts are enabled > within the interrupt handler. > > Fix this by unconditionally calling TRACE_IRQS_OFF when entering > interrupt handlers. Also call unconditionally TRACE_IRQS_ON when > leaving interrupts handlers. > > This leaves the special psw_idle() case, which now returns with > interrupts disabled, but has an "irqs on" lockdep state. So callers of > psw_idle() must adjust the state on their own, if required. This is > currently only __udelay_disabled(). > > Fixes: 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs tracing") > Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Thanks for sorting this Heiko!
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
| |