[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eeb87b48-aec9-4b3d-a0c1-afc83346b624@amd.com>
Date: Wed, 10 Sep 2025 16:50:13 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>
CC: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Peter Zijlstra
<peterz@...radead.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>,
Steven Rostedt <rostedt@...dmis.org>, Sebastian Andrzej Siewior
<bigeasy@...utronix.de>, Arnd Bergmann <arnd@...db.de>,
<linux-arch@...r.kernel.org>
Subject: Re: [patch 08/12] rseq: Implement time slice extension enforcement
timer
Hello Thomas,
On 9/9/2025 4:30 AM, Thomas Gleixner wrote:
> The timer is armed when an extenstion was granted right before actually
nit. s/extenstion/extension/
> returning to user mode in rseq_exit_to_user_mode_restart().
[..snip..]
> +static void rseq_cancel_slice_extension_timer(void)
> +{
> + struct slice_timer *st = this_cpu_ptr(&slice_timer);
> +
> + /*
> + * st->cookie can be safely read as preemption is disabled and the
> + * timer is CPU local. The active check can obviously race with the
> + * hrtimer interrupt, but that's better than disabling interrupts
> + * unconditionaly right away.
nit. s/unconditionaly/unconditionally/
--
Thanks and Regards,
Prateek
Powered by blists - more mailing lists