From b5b67adcc17e3e74dbcda09ff3f8a4636aa53486 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 18 May 2024 19:40:22 +0200 Subject: Merging debian version 6.7.7-1. Signed-off-by: Daniel Baumann --- ...proper-comment-about-the-preempt-disable-.patch | 47 ---------------------- 1 file changed, 47 deletions(-) delete mode 100644 debian/patches-rt/0001-signal-Add-proper-comment-about-the-preempt-disable-.patch (limited to 'debian/patches-rt/0001-signal-Add-proper-comment-about-the-preempt-disable-.patch') diff --git a/debian/patches-rt/0001-signal-Add-proper-comment-about-the-preempt-disable-.patch b/debian/patches-rt/0001-signal-Add-proper-comment-about-the-preempt-disable-.patch deleted file mode 100644 index e00261d790..0000000000 --- a/debian/patches-rt/0001-signal-Add-proper-comment-about-the-preempt-disable-.patch +++ /dev/null @@ -1,47 +0,0 @@ -From: Sebastian Andrzej Siewior -Date: Thu, 3 Aug 2023 12:09:31 +0200 -Subject: [PATCH 1/2] signal: Add proper comment about the preempt-disable in - ptrace_stop(). -Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/6.6/older/patches-6.6.7-rt18.tar.xz - -Commit 53da1d9456fe7 ("fix ptrace slowness") added a preempt-disable section -between read_unlock() and the following schedule() invocation without -explaining why it is needed. - -Replace the comment with an explanation why this is needed. Clarify that -it is needed for correctness but for performance reasons. - -Acked-by: Oleg Nesterov -Signed-off-by: Sebastian Andrzej Siewior -Link: https://lore.kernel.org/r/20230803100932.325870-2-bigeasy@linutronix.de ---- - kernel/signal.c | 17 ++++++++++++++--- - 1 file changed, 14 insertions(+), 3 deletions(-) - ---- a/kernel/signal.c -+++ b/kernel/signal.c -@@ -2329,10 +2329,21 @@ static int ptrace_stop(int exit_code, in - do_notify_parent_cldstop(current, false, why); - - /* -- * Don't want to allow preemption here, because -- * sys_ptrace() needs this task to be inactive. -+ * The previous do_notify_parent_cldstop() invocation woke ptracer. -+ * One a PREEMPTION kernel this can result in preemption requirement -+ * which will be fulfilled after read_unlock() and the ptracer will be -+ * put on the CPU. -+ * The ptracer is in wait_task_inactive(, __TASK_TRACED) waiting for -+ * this task wait in schedule(). If this task gets preempted then it -+ * remains enqueued on the runqueue. The ptracer will observe this and -+ * then sleep for a delay of one HZ tick. In the meantime this task -+ * gets scheduled, enters schedule() and will wait for the ptracer. - * -- * XXX: implement read_unlock_no_resched(). -+ * This preemption point is not bad from correctness point of view but -+ * extends the runtime by one HZ tick time due to the ptracer's sleep. -+ * The preempt-disable section ensures that there will be no preemption -+ * between unlock and schedule() and so improving the performance since -+ * the ptracer has no reason to sleep. - */ - preempt_disable(); - read_unlock(&tasklist_lock); -- cgit v1.2.3