On Fri, Mar 20, 2026 at 10:20:37AM -0400, Mathieu Desnoyers wrote: > On 2026-03-20 09:31, Mathieu Desnoyers wrote: > > On 2026-03-20 09:21, Harry Yoo (Oracle) wrote: > > > 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/20260227153730.1556542-4- > > > > > > [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: > > [...] > > One thing we could do to catch this kind of init sequence issue > is to add a WARN_ON_ONCE in percpu_counter_tree_items_size: > > size_t percpu_counter_tree_items_size(void) > { > if (WARN_ON_ONCE(!nr_cpus_order)) > return 0; > return counter_config->nr_items * sizeof(struct > percpu_counter_tree_level_item);
Looks good! -- Cheers, Harry / Hyeonggon
