[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wm49we9u.ffs@tglx>
Date: Sat, 01 Nov 2025 23:59:09 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, LKML
<linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Gabriele Monaco
<gmonaco@...hat.com>, Michael Jeanson <mjeanson@...icios.com>, Jens Axboe
<axboe@...nel.dk>, "Paul E. McKenney" <paulmck@...nel.org>, "Gautham R.
Shenoy" <gautham.shenoy@....com>, Florian Weimer <fweimer@...hat.com>, Tim
Chen <tim.c.chen@...el.com>, Yury Norov <yury.norov@...il.com>, Shrikanth
Hegde <sshegde@...ux.ibm.com>
Subject: Re: [patch V3 09/20] cpumask: Cache num_possible_cpus()
On Wed, Oct 29 2025 at 22:11, Thomas Gleixner wrote:
> On Wed, Oct 29 2025 at 11:54, Mathieu Desnoyers wrote:
>> On 2025-10-29 09:09, Thomas Gleixner wrote:
>> [...]
>>>
>>> +void set_cpu_possible(unsigned int cpu, bool possible)
>>
>> Unless I'm missing something, I suspect that "set_cpu_possible()" should
>> be marked as __init.
>
> Good point!
And only wishful thinking as set_cpu_possible() is wrongly used in code
which is not marked __init all over the architecture zoo. Cleaning that
up is yet another massive patch series dealing with mostly unmaintained
code. A nice task for people who want to get started with kernel
development. :)
On anything contemporary invoking set_cpu_possible() after init is going
to crash and burn because the related cpumask and variables are marked
RO at that point.
I've just addded a comment to that effect above the function to prevent
people from trying casually.
Thanks,
tglx
Powered by blists - more mailing lists