linux-kernel - Re: [PATCH v2 12/13] arm64: mm: Wrap flush_tlb_page() around ___flush_tlb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260127140816.00001b43@huawei.com>
Date: Tue, 27 Jan 2026 14:08:16 +0000
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: Ryan Roberts <ryan.roberts@....com>
CC: Will Deacon <will@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, Catalin
 Marinas <catalin.marinas@....com>, Mark Rutland <mark.rutland@....com>, Linus
 Torvalds <torvalds@...ux-foundation.org>, Oliver Upton
	<oliver.upton@...ux.dev>, Marc Zyngier <maz@...nel.org>, "Dev Jain"
	<dev.jain@....com>, Linu Cherian <Linu.Cherian@....com>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 12/13] arm64: mm: Wrap flush_tlb_page() around
 ___flush_tlb_range()

On Tue, 27 Jan 2026 14:03:43 +0000
Ryan Roberts <ryan.roberts@....com> wrote:

> On 27/01/2026 12:59, Jonathan Cameron wrote:
> > On Mon, 19 Jan 2026 17:21:59 +0000
> > Ryan Roberts <ryan.roberts@....com> wrote:
> >   
> >> Flushing a page from the tlb is just a special case of flushing a range.
> >> So let's rework flush_tlb_page() so that it simply wraps
> >> ___flush_tlb_range(). While at it, let's also update the API to take the
> >> same flags that we use when flushing a range. This allows us to delete
> >> all the ugly "_nosync", "_local" and "_nonotify" variants.
> >>
> >> Thanks to constant folding, all of the complex looping and tlbi-by-range
> >> options get eliminated so that the generated code for flush_tlb_page()
> >> looks very similar to the previous version.
> >>
> >> Reviewed-by: Linu Cherian <linu.cherian@....com>
> >> Signed-off-by: Ryan Roberts <ryan.roberts@....com>  
> > 
> > So this does include the use of the
> > 
> > Case TLBF_NOBROADCAST from previous patch, but only whilst (I think)
> > slightly changing behavior.
> > 
> > Gah.  I'm regretting looking at this series. The original code is really hard to
> > read :)  Rather you than me to fix it!
> >   
> >>  static inline void flush_tlb_kernel_range(unsigned long start, unsigned long end)
> >>  {
> >>  	const unsigned long stride = PAGE_SIZE;
> >> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> >> index be9dab2c7d6a..f91aa686f142 100644
> >> --- a/arch/arm64/mm/fault.c
> >> +++ b/arch/arm64/mm/fault.c
> >> @@ -239,7 +239,7 @@ int __ptep_set_access_flags(struct vm_area_struct *vma,
> >>  	 * flush_tlb_fix_spurious_fault().
> >>  	 */
> >>  	if (dirty)
> >> -		local_flush_tlb_page(vma, address);
> >> +		__flush_tlb_page(vma, address, TLBF_NOBROADCAST);  
> > 
> > Ultimately I think this previously did __tlbi(vale1) and now does __tlbi(vae1)
> > Original call was to __local_flush_tlb_page_notify_nosync()  
> 
> No not quite; the new code is still doing __tlbi(vale1).
> 
> The trick is that the __flush_tlb_page() wrapper unconditionally adds
> TLBF_NOWALKCACHE to the flags. Since this API is operating on a *page* it is
> implicit that we should only be evicting a leaf entry (as per the old
> implementation).
> 
> You'll see I've also updated the documentation to make that clear in tlbflush.h.
> 
> Now that you have raised it, I can see how it might be confusing though, since
> __flush_tlb_page() does not explicitly have TLBF_NOWALKCACHE. We could require
> all __flush_tlb_page() callers to explicitly pass TLBF_NOWALKCACHE if you think
> that helps? It would still be implicit for flush_tlb_page() (the generic kernel
> API) though.

Ah. I'd indeed missed that tweaking of the flags.

Not sure. You probably have a better feel for this ABI than I do and the likely
expectations of users.

J

> 
> > 
> > I'd like to see that sort of change called out and explained in the patch description.
> > It's a broader scoped flush so not a bug, but still a functional change.  
> 
> As I say, the emitted code is the same. It's my new API that's the problem here...

> 
> Thanks,
> Ryan
> 
> >   
> >>  	return 1;
> >>  }
> >>    
> >   
> 
>