++ linuxppc-dev
Mathieu Desnoyers <[email protected]> writes: > 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: Even though powerpc is showing the warning because of VM_WARN_ON_ONCE(), but this looks more of a generic problem, where use of mm_cpumask() before and after percpu_counter_tree_items_size() could lead to different results (as you also pointed above). Looks like this is causing regressions in linux-next with warnings similar to what Harry also pointed out. Do we have any solution for this, or are we planning to hold on to this patch[1] and maybe even remove it temporarily from linux-next, until this is fixed? [1]: https://lore.kernel.org/all/[email protected]/ [ 0.000000] WARNING: arch/powerpc/mm/mmu_context.c:106 at switch_mm_irqs_off+0x1a0/0x1d0, CPU#2: swapper/0 [ 0.000000] Modules linked in: [ 0.000000] CPU: 2 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-rc4-next-20260317-00008-g5585e414f073 #4 PREEMPTLAZY [ 0.000000] Hardware name: IBM PowerNV (emulated by qemu) POWER10 0x801200 opal:v7.1 PowerNV [ 0.000000] NIP: c00000000008f3b0 LR: c00000000008f330 CTR: c000000000090e20 [ 0.000000] REGS: c000000003cb79b0 TRAP: 0700 Not tainted (7.0.0-rc4-next-20260317-00008-g5585e414f073) [ 0.000000] MSR: 9000000002021033 <SF,HV,VEC,ME,IR,DR,RI,LE> CR:24022224 XER: 00000000 <...> [ 0.000000] NIP [c00000000008f3b0] switch_mm_irqs_off+0x1a0/0x1d0 [ 0.000000] LR [c00000000008f330] switch_mm_irqs_off+0x120/0x1d0 [ 0.000000] Call Trace: [ 0.000000] [c000000003cb7c50] [0500210400000080] 0x500210400000080 (unreliable) [ 0.000000] [c000000003cb7cb0] [c0000000000ad850] start_using_temp_mm+0x34/0xb0 [ 0.000000] [c000000003cb7cf0] [c0000000000ae8b8] patch_mem+0x110/0x530 [ 0.000000] [c000000003cb7d70] [c000000000077f30] ftrace_modify_code+0x114/0x154 [ 0.000000] [c000000003cb7dd0] [c00000000036a690] ftrace_process_locs+0x408/0x810 [ 0.000000] [c000000003cb7ec0] [c0000000030584ec] ftrace_init+0x68/0x1c4 [ 0.000000] [c000000003cb7f30] [c00000000300d3b8] start_kernel+0x680/0xc44 [ 0.000000] [c000000003cb7fe0] [c00000000000e99c] start_here_common+0x1c/0x20 -ritesh
