[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20221024104425.16423-7-wagi@monom.org>
Date: Mon, 24 Oct 2022 12:44:22 +0200
From: Daniel Wagner <wagi@...om.org>
To: LKML <linux-kernel@...r.kernel.org>,
linux-rt-users <linux-rt-users@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Carsten Emde <C.Emde@...dl.org>,
John Kacur <jkacur@...hat.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Tom Zanussi <tom.zanussi@...ux.intel.com>,
Clark Williams <williams@...hat.com>,
Pavel Machek <pavel@...x.de>
Cc: Mike Galbraith <efault@....de>, Daniel Wagner <wagi@...om.org>
Subject: [PATCH RT 6/9] timers: Don't block on ->expiry_lock for TIMER_IRQSAFE timers
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
v4.19.255-rt114-rc1 stable review patch.
If anyone has any objections, please let me know.
-----------
Upstream commit c725dafc95f1b37027840aaeaa8b7e4e9cd20516
PREEMPT_RT does not spin and wait until a running timer completes its
callback but instead it blocks on a sleeping lock to prevent a livelock in
the case that the task waiting for the callback completion preempted the
callback.
This cannot be done for timers flagged with TIMER_IRQSAFE. These timers can
be canceled from an interrupt disabled context even on RT kernels.
The expiry callback of such timers is invoked with interrupts disabled so
there is no need to use the expiry lock mechanism because obviously the
callback cannot be preempted even on RT kernels.
Do not use the timer_base::expiry_lock mechanism when waiting for a running
callback to complete if the timer is flagged with TIMER_IRQSAFE.
Also add a lockdep assertion for RT kernels to validate that the expiry
lock mechanism is always invoked in preemptible context.
Reported-by: Mike Galbraith <efault@....de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Link: https://lore.kernel.org/r/20201103190937.hga67rqhvknki3tp@linutronix.de
[bigeasy: The logic in v4.19 is slightly different but the outcome is the
same as we must not sleep while waiting for the irqsafe timer to
complete. The IRQSAFE timer can not be preempted.
The "lockdep annotation" is not available and has been replaced with
might_sleep()]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Signed-off-by: Daniel Wagner <wagi@...om.org>
---
kernel/time/timer.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 3e2c0bd03004..0a6d60b3e67c 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1272,6 +1272,9 @@ static int __del_timer_sync(struct timer_list *timer)
if (ret >= 0)
return ret;
+ if (READ_ONCE(timer->flags) & TIMER_IRQSAFE)
+ continue;
+
/*
* When accessing the lock, timers of base are no longer expired
* and so timer is no longer running.
@@ -1336,6 +1339,12 @@ int del_timer_sync(struct timer_list *timer)
* could lead to deadlock.
*/
WARN_ON(in_irq() && !(timer->flags & TIMER_IRQSAFE));
+ /*
+ * Must be able to sleep on PREEMPT_RT because of the slowpath in
+ * __del_timer_sync().
+ */
+ if (IS_ENABLED(CONFIG_PREEMPT_RT) && !(timer->flags & TIMER_IRQSAFE))
+ might_sleep();
return __del_timer_sync(timer);
}
--
2.38.0
Powered by blists - more mailing lists