Message-ID: <aXC45qHHYiAgZgKn@e129823.arm.com>
Date: Wed, 21 Jan 2026 11:30:46 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Ryan Roberts <ryan.roberts@....com>
Cc: Yang Shi <yang@...amperecomputing.com>, Will Deacon <will@...nel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev, catalin.marinas@....com,
	akpm@...ux-oundation.org, david@...nel.org, kevin.brodsky@....com,
	quic_zhenhuah@...cinc.com, dev.jain@....com,
	chaitanyas.prakash@....com, bigeasy@...utronix.de,
	clrkwllms@...nel.org, rostedt@...dmis.org,
	lorenzo.stoakes@...cle.com, ardb@...nel.org, jackmanb@...gle.com,
	vbabka@...e.cz, mhocko@...e.com
Subject: Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while
 splitting the linear mapping

On Wed, Jan 21, 2026 at 10:20:52AM +0000, Ryan Roberts wrote:
> On 21/01/2026 08:32, Yeoreum Yun wrote:
> >>>> My concern is that if a secondary CPU can race and cause a split, that is
> >>>> unsound because we have determined that although the primary CPU supports BBML2,
> >>>> at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
> >>>>
> >>>> I just had a brief chat with Rutland, and he agrees that this _could_ be a
> >>>> problem. Basically there is a window between onlining the secondary cpus and
> >>>> entering the stop_machine() where one of those cpus _could_ end up doing
> >>>> something that causes us to split the linear map.
> >>
> >> If I remember correctly, split_kernel_leaf_mapping() does call
> >> system_supports_bbml2_noabort() before doing real split. So we basically
> >> should fall into two categories:
> >>
> >> 1. bbml2_noabort is supported on all cpus. Everything is fine.
> >> 2. bbml2_noabort is not supported on all cpus. split_kernel_leaf_mapping()
> >> just returns 0. Kernel doesn't split page table, so there won't be TLB
> >> conflict issue. But the following page prot update may see unexpected block
> >> mapping, then a   WARN  will be raised and it will return -EINVAL. So the
> >> worst case is the caller will fail (IIRC all the callers of set_memory_*()
> >> handle the failure), and we can know who is trying to change linear mapping
> >> before the linear mapping gets                    finalized. AFAICT I
> >> haven't seen such WARN yet.
>
> Ahh good point! So this isn't quite as terrible as I was thinking.
>
> >
> > Thanks for the great detail :)
> > I've missed system_supports_bbml2_noabort() in split_kernel_leaf_mapping().
> >
> >>
> >>>>
> >>>> I'm not immediately sure how to solve that.
> >>
> >> Do we need some synchronization mechanism? If the linear mapping is not
> >> finalized yet, split_kernel_leaf_mapping() will spin. For example, something
> >> like this off the top of my head,
> >>
> >> DEFINE_STATIC_KEY_FALSE(linear_mapping_finalized);
> >>
> >> Once the linear mapping is finalized, we can call
> >> static_branch_enable(&linear_mapping_finalized);
> >>
> >> In split_kernel_leaf_mapping(), we can just do:
> >>
> >> retry:
> >>     if (!static_branch_likely(&linear_mapping_finalized))
> >>         goto retry;
> >>
>
> Yuck... But I guess it might work as long as the primary thread never does
> anything that would cause an attempt to split; otherwise we have a deadlock.
>
> >>
> >> There may be better way to handle it. But this case should be very unlikely
> >> IMHO. It sounds crazy to have such complicated kernel threads run so early.
> >> I'm not sure whether we should pay immediate attention to it or not.
>
> I think we need to figure out if this is actually possible. We bring up the
> secondary cpus, set system caps and finalize the linear map in smp_init().
> That's called from kernel_init_freeable() which is called from kernel_init(),
> which is invoked as a thread pinned to the boot cpu.
>
> sched_init_smp() is called after smp_init() (i.e. after the linear map is
> finalized). I'm guessing (based on the name of sched_init_smp()) that nothing
> other than the idle thread will run on any secondaries until after
> sched_init_smp() is called? (I'd be greatful if anyone can confirm that).
>
> Rutland suggested that it's probably too early for any PM type stuff to be
> running in the idle loop, so based on all of that, perhaps this is not a problem
> after all and there is basically zero chance of a secondary cpu doing anything
> that could cause a linear map split during this window?
>
> I'm inclined to leave this as is for now.

IIUC, since it before the sched_domain creation yet,
the wake_up_new_task()'s cpu selection via select_task_rq_fair()
would be always the same for prev_cpu. So I agree with you
this case would be a zero chance of a scondary cpu doing anything.

>
> Thanks,
> Ryan
>
> >
> > Thinking about it again, I’m not sure whether
> > it is acceptable to use a sleepable synchronization mechanism at this stage,
> > like split_kernel_leaf_mapping() does with mutex_lock()
> > (even though it may be technically possible).
> > It also feels odd that this function can be called at this point in time.
> >
> > If this is indeed considered problematic,
> > I think it would be better to simply return -EINVAL immediately
> > when linear_mapping_finalized has not yet been completed.
> >
> > --
> > Sincerely,
> > Yeoreum Yun
>

--
Sincerely,
Yeoreum Yun

Powered by blists - more mailing lists