[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fraiex2u.ffs@tglx>
Date: Wed, 12 Nov 2025 22:54:17 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Prakash Sangappa
<prakash.sangappa@...cle.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Peter Zijlstra
<peterz@...radead.org>, "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 00/12] rseq: Implement time slice extension mechanism
On Wed, Nov 12 2025 at 15:46, Mathieu Desnoyers wrote:
> On 2025-11-12 15:31, Thomas Gleixner wrote:
>> I did not notice the V3 issue because tests passed on a small machine,
>> but after I did a rebase to the tip rseq and uaccess bits, I noticed the
>> failure because I tested on a larger box.
>
> Good ! We'll see if this fixes the issue observed by Prakash. If not,
> I'm curious to validate that num_possible_cpus() is always set to its
> final value before _any_ mm is created.
It _is_ set to it's final value in start_kernel() before
setup_per_cpu_areas() is invoked. Otherwise the kernel would not work at
all.
Powered by blists - more mailing lists