Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

Ryan Roberts
2026-01-22T13:47:22Z

>>> I'm inclined to leave this as is for now.
>>
>> I agree. I don't think this would be a real problem.
>>
>> Thanks,
>> Yang
>
> Although partially using GFP_ATOMIC might not be an issue given that
> there is no contention at the moment,
> technically using a memory allocation API inside stop_machine() is problematic
> for PREEMPT_RT, and the relevant page tables should be pre-allocated.
>
> That said, taking a step back (I’m not sure why I was being so stubborn about this),
> since the kernel_alias area is mapped using block mappings,
> a simple calculation based on your dm_meminfo patch should be sufficient to
> determine the number of page tables that need to be pre-allocated for
> splitting the linear mapping, without having to walk the page tables again.
>
> So, after your dm_meminfo patch, I plan to respin this patch based on that.
>
> Am I missing anything?

Yeoreum and I had an offline chat about all this and I just want to spell out
the conclusion for everybody;

We believe it's impossible for the secondary CPUs to have any scheduled work
during this window, and therefore it's impossible for the split race to occur,
and it's impossible for there to be any contention on the page allocator lock.
All of which means that in practice, there are no bugs here and the code is safe
as is, even for PREEMPT_RT.

That said, allocating memory inside of stop_machine() is a bad smell, so Yeoreum
will rectify this down the track; it's not urgent though.

Thanks,
Ryan