Re: [RFC PATCH 10/34] x86: mm: carve out the generic compile-time folded pgtable case in effective_prot()

On 7/21/26 19:45, Yeoreum Yun wrote:
> Hi,
> 
>>>
>>> Yes, exactly. :)
>>>
>>> And I agree that it is something we should be optimizing.
>>>
>>>
>>> I'd be curious about that as well. I mean, looking at the generated code
>>> it's clear that it is suboptimal.
>>>
>>>
>>> The solution space I see:
>>>
>>>
>>> (1) Pass the result from e.g., pgdp_get() into p4d_get(), so it can just return 
>>>     the value with folded p4ds.
>>>
>>> That requires extreme amounts of churn in core-mm AFAIKS, so I don't see that as feasible.
>>>
>>>
>>> (2) Rewrite folding code to make p4d_present() be a dummy instead of 
>>>     pgd_present(), and make p4dp_get() return a dummy value.
>>>
>>> ... a lot of churn across architectures. I'm sure we'll learn soon why it was done 
>>> ike the way it is today in the first place. Something interesting to look at,
>>> certainly, but a bit of a stretch just to optimize reads.
>>>
>>>
>>> (3) Make folded pgdp_get() use an ordinary read instead of a READ_ONCE / dummy.
>>>
>>> I don't like that, because we couldn't catch easily if the value is then
>>> actually used some old/new code.
>>>
>>> If pgd_present() etc are supposed to ignore the value, I'd rather have a mechanism
>>> that enforces that the values are actually ignore in pgd_offset() etc as well.
>>>
>>>
>>> (4) What we do in this series, but instead of forbidding set_pgd(), make it only 
>>>     complain when we are passing in a dummy value.
>>>
>>> The expectation is that it would avoid touching most architecture code in patch
>>> 12 -> 27 and still prevent mistakes in the future.
>>>
>>> @Yeoreum can you play with that and see what the end result would be?
> 
> If there's no comment anymore for (4), Could I post next version on tomorrow?

Works for me.

As discussed off-list, we should look into de-duplicating some of the arch
vmalloc_fault fixup code, but that will be a separate effort.

-- 
Cheers,

David