On Fri, Mar 20, 2026 at 08:35:46AM -0400, Mathieu Desnoyers wrote: > On 2026-03-20 00:17, Harry Yoo wrote: > [...] > > > [1]: > > > https://lore.kernel.org/[email protected]/ > > > > @Mathieu: In patch 1/3 description, > > > Changes since v7: > > > - Explicitly initialize the subsystem from start_kernel() right > > > after mm_core_init() so it is up and running before the creation of > > > the first mm at boot. > > > > But how does this work when someone calls mm_cpumask() on init_mm early? > > Looks like it will behave incorrectly because get_rss_stat_items_size() > > returns zero? > > It doesn't work as expected at all. I missed that all users of mm_cpumask() > end up relying on get_rss_stat_items_size(), which now calls > percpu_counter_tree_items_size(), which depends on initialization from > percpu_counter_tree_subsystem_init(). > > If you add a call to percpu_counter_tree_subsystem_init in > arch/powerpc/kernel/setup_arch() just before: > > VM_WARN_ON(cpumask_test_cpu(smp_processor_id(), > mm_cpumask(&init_mm))); > cpumask_set_cpu(smp_processor_id(), mm_cpumask(&init_mm)); > > Does the warning go away ?
Hmm it goes away, but I'm not sure if it is it okay to use nr_cpu_ids before setup_nr_cpu_ids() is called? > Alternatively, would could use a lazy initialization invoking > percpu_counter_tree_subsystem_init from percpu_counter_tree_items_size > when the initialization is not already done. So this probably isn't a way to go? Hmm perhaps we should treat init_mm as a special case in mm_cpus_allowed() and mm_cpumask(). -- Cheers, Harry / Hyeonggon
