linux-kernel - Re: [patch V6 10/11] entry: Hook up rseq time slice extension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260117095114.GF1890602@noisy.programming.kicks-ass.net>
Date: Sat, 17 Jan 2026 10:51:14 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...nel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>, Jonathan Corbet <corbet@....net>,
	Prakash Sangappa <prakash.sangappa@...cle.com>,
	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,
	Randy Dunlap <rdunlap@...radead.org>,
	Ron Geva <rongevarg@...il.com>, Waiman Long <longman@...hat.com>
Subject: Re: [patch V6 10/11] entry: Hook up rseq time slice extension

On Sun, Jan 11, 2026 at 12:01:31PM +0100, Thomas Gleixner wrote:

> I know you argued about this many times, but I still maintain my point
> of view that TIF_PREEMPT and TIF_PREEMPT_LAZY are fundmentally different:
> 
>      TIF_PREEMPT_LAZY grants a non-RT task to complete until it reaches
>      return to user
> 
>      TIF_PREEMPT enforces preemption at the next possible preemption
>      point

This is only true for lazy preemption; and that is not the only possible
model.

> My main concern is this scenario:
> 
>    sched_other_task()
>         request_slice_extension()
> 
>    ---> interrupt
>         RT task is woken up
> 
>         return_to_user()
>            grant_extension()
>            ...
> 
> which means the RT task is delayed until the OTHER task relinquishes the
> CPU voluntarily or via timeout.

Which is exactly the same as if there were a kernel preempt_disable()
region.

> So I prefer to keep the current semantics for RT. This can be revisited
> of course when a proper evaluation has been done, but IMO there are too
> many moving parts in a RT system to make this actually work correctly
> under all circumstances.
> 
> I'll add proper comments to that effect.

I've added:

+/*
+ * Since rseq slice ext has a direct correlation to the worst case
+ * scheduling latency (schedule is delayed after all), only have it affect
+ * LAZY reschedules on PREEMPT_RT for now.
+ *
+ * However, since this delay is only applicable to userspace, a value
+ * for rseq_slice_extension_nsec that is strictly less than the worst case
+ * kernel space preempt_disable() region, should mean the scheduling latency
+ * is not affected, even for !LAZY.
+ *
+ * However, since this value depends on the hardware at hand, it cannot be
+ * pre-determined in any sensible way. Hence punt on this problem for now.
+ */