[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <874iqqm4dr.ffs@tglx>
Date: Wed, 19 Nov 2025 16:25:03 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Prakash Sangappa <prakash.sangappa@...cle.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Peter Zijlstra
<peterz@...radead.org>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, "Paul E. McKenney" <paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, Jonathan Corbet <corbet@....net>,
Madadi Vineeth Reddy <vineethr@...ux.ibm.com>, K Prateek Nayak
<kprateek.nayak@....com>, Steven
Rostedt <rostedt@...dmis.org>, Sebastian Andrzej Siewior
<bigeasy@...utronix.de>, Arnd Bergmann <arnd@...db.de>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [patch V3 07/12] rseq: Implement syscall entry work for time
slice extensions
On Wed, Nov 19 2025 at 00:20, Prakash Sangappa wrote:
>> On Oct 29, 2025, at 6:22 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>> + if (put_user(0U, &curr->rseq.usrptr->slice_ctrl.all) || syscall != __NR_rseq_slice_yield)
>> + force_sig(SIGSEGV);
>> +}
>
> I have been trying to get our Database team to implement changes to
> use the slice extension API. They encounter the issue with a system
> call being made within the slice extension window and the process dies
> with SEGV.
Good. Works as designed.
> Apparently it will be hard to enforce not calling a system call in the
> slice extension window due to layering.
Why do I have a smell of rotten onions in my nose right now?
> For the DB use case, It is fine to terminate the slice extension if a
> system call is made, but the process getting killed will not work.
That's not a question of being fine or not.
The point is that on PREEMPT_NONE/VOLUNATRY that arbitrary syscall can
consume tons of CPU cycles until it either schedules out voluntarily or
reaches __exit_to_user_mode_loop(), which is defeating the whole
mechanism. The timer does not help in that case because once the task is
in the kernel it won't be preempted on return from interrupt.
sys_rseq_sched_yield() is time bound, which is why it was implemented
that way.
I was absolutely right when I asked to tie this mechanism to
PREEMPT_LAZY|FULL in the first place. That would nicely avoid the whole
problem.
Something like the uncompiled and untested below should work. Though I
hate it with a passion.
Thanks,
tglx
---
Subject: rseq/slice: Handle rotten onions gracefully
From: Thomas Gleixner <tglx@...utronix.de>
Date: Wed, 19 Nov 2025 16:07:15 +0100
Add rant here.
Not-Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
---
kernel/rseq.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -643,13 +643,21 @@ void rseq_syscall_enter_work(long syscal
}
curr->rseq.slice.state.granted = false;
+ /* Clear the grant in user space. */
+ if (put_user(0U, &curr->rseq.usrptr->slice_ctrl.all))
+ force_sig(SIGSEGV);
+
/*
- * Clear the grant in user space and check whether this was the
- * correct syscall to yield. If the user access fails or the task
- * used an arbitrary syscall, terminate it.
+ * Grudgingly support onion layer applications which cannot
+ * guarantee that rseq_slice_yield() is used to yield the CPU for
+ * terminating a grant. This is a NOP on PREEMPT_FULL/LAZY because
+ * enabling preemption above already scheduled, but required for
+ * PREEMPT_NONE/VOLUNTARY to prevent that the slice is further
+ * expanded up to the point where the syscall code schedules
+ * voluntarily or reaches exit_to_user_mode_loop().
*/
- if (put_user(0U, &curr->rseq.usrptr->slice_ctrl.all) || syscall != __NR_rseq_slice_yield)
- force_sig(SIGSEGV);
+ if (syscall != __NR_rseq_slice_yield)
+ cond_resched();
}
int rseq_slice_extension_prctl(unsigned long arg2, unsigned long arg3)
Powered by blists - more mailing lists