linux-kernel - Re: [PATCH v2 11/13] arm64: mm: More flags for __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] [day] [month] [year] [list]

Message-ID: <a3cc1c57-51e1-41c7-acf4-b398ca9b989f@arm.com>
Date: Tue, 27 Jan 2026 14:47:04 +0000
From: Ryan Roberts <ryan.roberts@....com>
To: Jonathan Cameron <jonathan.cameron@...wei.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 11/13] arm64: mm: More flags for __flush_tlb_range()

On 27/01/2026 14:14, Jonathan Cameron wrote:
> On Tue, 27 Jan 2026 14:11:37 +0000
> Jonathan Cameron <jonathan.cameron@...wei.com> wrote:
> 
>> On Tue, 27 Jan 2026 13:50:06 +0000
>> Ryan Roberts <ryan.roberts@....com> wrote:
>>
>>> On 27/01/2026 12:45, Jonathan Cameron wrote:  
>>>> On Mon, 19 Jan 2026 17:21:58 +0000
>>>> Ryan Roberts <ryan.roberts@....com> wrote:
>>>>     
>>>>> Refactor function variants with "_nosync", "_local" and "_nonotify" into
>>>>> a single __always_inline implementation that takes flags and rely on
>>>>> constant folding to select the parts that are actually needed at any
>>>>> given callsite, based on the provided flags.
>>>>>
>>>>> Flags all live in the tlbf_t (TLB flags) type; TLBF_NONE (0) continues
>>>>> to provide the strongest semantics (i.e. evict from walk cache,
>>>>> broadcast, synchronise and notify). Each flag reduces the strength in
>>>>> some way; TLBF_NONOTIFY, TLBF_NOSYNC and TLBF_NOBROADCAST are added to
>>>>> complement the existing TLBF_NOWALKCACHE.    
>>>>
>>>> Unless I'm missing something the case of TLBF_NOBROADCAST but not
>>>> TLBF_NOWALKCACHE isn't currently used.    
>>>
>>> Currect but the next couple of patches start using TLBF_NOBROADCAST without
>>> TLBF_NOWALKCACHE. TLBF_NOWALKCACHE is used without TLBF_NOBROADCAST in this patch.
>>>   
>>>>   
>>>> I wonder if bringing that in with a user will make it easier to see what
>>>> is going on.    
>>>
>>> I'm not sure I understand the suggestion. This patch is using both flags so I
>>> can't really defer introducing one of them. It's just that (for this patch only)
>>> it never uses TLBF_NOBROADCAST without TLBF_NOWALKCACHE.  
>>
>> Would be a case of lobbing in a build_bug_on() or similar, but this was
>> mainly that I hadn't read the later patches at this point (or at least
>> not such that they were still in my memory).
>>
>> Perhaps a breadcrumb just to say that new combination is added, but
>> not used until later patches.
> 
> Now I'm going crazy. Is it used used in this series?  After you pointed out
> the addition of TLBF_NOWALKCACHE in the flush page stuff I'm failing to spot
> that. Or do you mean in a follow up series?

Yeah, you're right; sorry about that. ___flush_tlb_range() (3 underscores) never
sees TLBF_NOBROADCAST without TLBF_NOWALKCACHE. (I also failed to see the tweek
in __flush_tlb_page() when I first responded to this. There is no follow up series).

I'll replace the vae1 option with a BUILD_BUG() and remove the vae1()/rvae1()
helpers in the next version.

Thanks for the review!

Thanks,
Ryan