diff options
author | Salvatore Bonaccorso <carnil@debian.org> | 2019-12-18 18:06:31 +0100 |
---|---|---|
committer | Salvatore Bonaccorso <carnil@debian.org> | 2019-12-18 22:50:21 +0100 |
commit | 102987a83771aa994821d4d982d06faa64c789e4 (patch) | |
tree | 3e5ab5206886ec297a1a97ce80f504d75468ed2f /debian/patches-rt/locking-rtmutex-Clean-pi_blocked_on-in-the-error-cas.patch | |
parent | 479cb120ecb2b3f2c4d929a7b57860248d6f79bd (diff) | |
download | linux-debian-102987a83771aa994821d4d982d06faa64c789e4.tar.gz |
[rt] Update to 5.4.3-rt1 and re-enable
Adjust for context changes due to backport of
e66b39af00f4 ("workqueue: Fix pwq ref leak in rescuer_thread()") and
def98c84b6cd ("workqueue: Fix spurious sanity check failures in
destroy_workqueue()") in 5.4.4.
Diffstat (limited to 'debian/patches-rt/locking-rtmutex-Clean-pi_blocked_on-in-the-error-cas.patch')
-rw-r--r-- | debian/patches-rt/locking-rtmutex-Clean-pi_blocked_on-in-the-error-cas.patch | 92 |
1 files changed, 92 insertions, 0 deletions
diff --git a/debian/patches-rt/locking-rtmutex-Clean-pi_blocked_on-in-the-error-cas.patch b/debian/patches-rt/locking-rtmutex-Clean-pi_blocked_on-in-the-error-cas.patch new file mode 100644 index 000000000..52d9d4dd1 --- /dev/null +++ b/debian/patches-rt/locking-rtmutex-Clean-pi_blocked_on-in-the-error-cas.patch @@ -0,0 +1,92 @@ +From: Peter Zijlstra <peterz@infradead.org> +Date: Mon, 30 Sep 2019 18:15:44 +0200 +Subject: [PATCH] locking/rtmutex: Clean ->pi_blocked_on in the error case +Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/older/patches-5.4.3-rt1.tar.xz + +The function rt_mutex_wait_proxy_lock() cleans ->pi_blocked_on in case +of failure (timeout, signal). The same cleanup is required in +__rt_mutex_start_proxy_lock(). +In both the cases the tasks was interrupted by a signal or timeout while +acquiring the lock and after the interruption it longer blocks on the +lock. + +Fixes: 1a1fb985f2e2b ("futex: Handle early deadlock return correctly") +Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> +Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> +--- + kernel/locking/rtmutex.c | 43 +++++++++++++++++++++++++------------------ + 1 file changed, 25 insertions(+), 18 deletions(-) + +--- a/kernel/locking/rtmutex.c ++++ b/kernel/locking/rtmutex.c +@@ -2137,6 +2137,26 @@ void rt_mutex_proxy_unlock(struct rt_mut + rt_mutex_set_owner(lock, NULL); + } + ++static void fixup_rt_mutex_blocked(struct rt_mutex *lock) ++{ ++ struct task_struct *tsk = current; ++ /* ++ * RT has a problem here when the wait got interrupted by a timeout ++ * or a signal. task->pi_blocked_on is still set. The task must ++ * acquire the hash bucket lock when returning from this function. ++ * ++ * If the hash bucket lock is contended then the ++ * BUG_ON(rt_mutex_real_waiter(task->pi_blocked_on)) in ++ * task_blocks_on_rt_mutex() will trigger. This can be avoided by ++ * clearing task->pi_blocked_on which removes the task from the ++ * boosting chain of the rtmutex. That's correct because the task ++ * is not longer blocked on it. ++ */ ++ raw_spin_lock(&tsk->pi_lock); ++ tsk->pi_blocked_on = NULL; ++ raw_spin_unlock(&tsk->pi_lock); ++} ++ + /** + * __rt_mutex_start_proxy_lock() - Start lock acquisition for another task + * @lock: the rt_mutex to take +@@ -2209,6 +2229,9 @@ int __rt_mutex_start_proxy_lock(struct r + ret = 0; + } + ++ if (ret) ++ fixup_rt_mutex_blocked(lock); ++ + debug_rt_mutex_print_deadlock(waiter); + + return ret; +@@ -2289,7 +2312,6 @@ int rt_mutex_wait_proxy_lock(struct rt_m + struct hrtimer_sleeper *to, + struct rt_mutex_waiter *waiter) + { +- struct task_struct *tsk = current; + int ret; + + raw_spin_lock_irq(&lock->wait_lock); +@@ -2301,23 +2323,8 @@ int rt_mutex_wait_proxy_lock(struct rt_m + * have to fix that up. + */ + fixup_rt_mutex_waiters(lock); +- /* +- * RT has a problem here when the wait got interrupted by a timeout +- * or a signal. task->pi_blocked_on is still set. The task must +- * acquire the hash bucket lock when returning from this function. +- * +- * If the hash bucket lock is contended then the +- * BUG_ON(rt_mutex_real_waiter(task->pi_blocked_on)) in +- * task_blocks_on_rt_mutex() will trigger. This can be avoided by +- * clearing task->pi_blocked_on which removes the task from the +- * boosting chain of the rtmutex. That's correct because the task +- * is not longer blocked on it. +- */ +- if (ret) { +- raw_spin_lock(&tsk->pi_lock); +- tsk->pi_blocked_on = NULL; +- raw_spin_unlock(&tsk->pi_lock); +- } ++ if (ret) ++ fixup_rt_mutex_blocked(lock); + + raw_spin_unlock_irq(&lock->wait_lock); + |