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

Yang Shi
2026-01-21T00:12:28Z

>> 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.

>>
>> 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;

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.

Thanks,
Yang

>>
>> --
>> Sincerely,
>> Yeoreum Yun