Re: [PATCH 12/18] arm64: Implement try_populate_vmemmap_pmd using AF trick

James Houghton <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <CADrL8HXZy3HgQeHA6b8TzJX7oWc9goe30sPfP1F5OMUtWLbyBA@mail.gmail.com>
On Tue, Aug 18, 2026 at 9:34 AM Catalin Marinas <[email protected]> wrote:
>
> On Wed, Jul 08, 2026 at 03:11:22AM +0000, James Houghton wrote:
> > This routine is to be used for updating in-use, leaf-level PMDs in the
> > vmemmap without introducing a window where vmemmap accesses might fault.
> >
> > Implementing this on arm64 requires some care: use the same access flag
> > trick that is used for vmemmap PTE updates. HAFT is not needed and the
> > TLB flushing routine remains identical, as we are not overwriting a
> > non-leaf PMD.
> >
> > For systems that support BBML2_NOABORT, there is no need to use the AF
> > trick.
>
> This part needs even more text in the Arm ARM. With dropping of the
> BBML2_NOABORT requirement in patch 13, we are left with the D8.17.2
> rules in the Arm ARM (M.c) requiring BBM. I'm not sure we can infer much
> from the AF=0 caching rules as here we talk about the walk caches. For
> example, a walk cache memorises the VA to block descriptor translation
> and that's irrespective of the leaf entry AF bit. If AF=0 and you skip
> the TLBI, nothing flushes the walk cache which may confuse the CPU when
> it suddenly sees a table entry where it expected a block one.

The CPU must still respect block descriptors that become invalid, so
it wouldn't be able to just assume "this is a valid Block descriptor",
right? But I really don't know how implementations actually work here,
so it could be possible that the walk cache could get confused during
Block -> Table transitions without a BBM sequence.

I agree that this should be clarified. I'll try to prepare an HVO-less
description of the required behavior and work with Will to properly
ask about it.

> If it's not critical to the series, I suggest we leave this patch and
> the next one out for now.

I originally included it because I didn't have any machines with
BBML3, but I think I have a Neoverse N3 system which supports BBML3.
:)

I think I'll still include these patches anyway (it's at least useful
to continue to drive the discussion of whether or not the Block ->
Table transition is legal); I'll structure the series such that they
can be easily left off. And I'll note in the cover letter that they
probably ought to be merged separately after more scrutiny.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.