Re: [PATCH] arm64/mm: restrict transparent contpte mappings to valid PTEs

[Catalin Marinas]

On Mon, Oct 26, 2026 at 11:33:31PM +0100, David Hildenbrand wrote:
> On 10/26/26 13:30, Catalin Marinas wrote:
> > On Sun, Oct 25, 2026 at 12:00:33AM +0800, Zhao Gongyi wrote:
> >> On 10/24/26 4:55 AM, David Hildenbrand (Arm) wrote:
> >>> If we have the spare PTE bit, why shouldn't we just use it?
> >>>
> >>> It will make batching over PTEs faster. And we care about that for present PTEs.
> >>>
> >>> So I don't quite see why the stable fix couldn't just do it right away? Do you
> >>> have a prototype that shows that it would require significant code changes?
> >>
> >> I tried a small prototype that keeps PTE_CONT on present-invalid PTEs.
> >> It leaves contpte_set_ptes() unchanged and makes contpte_try_unfold()
> >> recognize pte_present(pte) && pte_cont(pte), instead of checking only
> >> pte_valid_cont(pte).
> > 
> > I think it's worth doing but currently not sure it buys us much unless
> > we also change pte_batch_hint() to cover such entries. However, if we do
> > this, we need to audit the other pte_valid_cont() callers (e.g.
> > ptep_get() needs updating as well).
> > 
> > So, if we aren't going to change pte_batch_hint() as a backport fix (I
> > don't think we should, it's an optimisation), I'd rather take v2 now and
> > continue with a proper pte_present_cont() etc. patchset on top.
> 
> Your call, the version actually looks quite clean:
> 
> https://lore.kernel.org/r/52e7e1f6-3535-474d-9b46-6bb62f96eefc@xxxxxxxxxxxxx
> 
> But yeah, audit needed (e.g., no need to flush when shattering such entries that
> are not valid)

Yes, the fix looked clean but I didn't particularly like the asymmetry
between try_fold and try_unfold w.r.t. pte_present(). Well, that's more
of an OCD ;).

Going forward I think we should move towards pte_present_cont() but
together with changing pte_batch_hint().

-- 
Catalin