linux-kernel - Re: [PATCH -v2 2/2] arm64, tlbflush: don't TLBI broadcast if page reused in write fault

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: <871pmv9unr.fsf@DESKTOP-5N7EMDA>
Date: Wed, 22 Oct 2025 17:02:00 +0800
From: "Huang, Ying" <ying.huang@...ux.alibaba.com>
To: Barry Song <21cnbao@...il.com>
Cc: Catalin Marinas <catalin.marinas@....com>,  Will Deacon
 <will@...nel.org>,  Andrew Morton <akpm@...ux-foundation.org>,  David
 Hildenbrand <david@...hat.com>,  Lorenzo Stoakes
 <lorenzo.stoakes@...cle.com>,  Vlastimil Babka <vbabka@...e.cz>,  Zi Yan
 <ziy@...dia.com>,  Baolin Wang <baolin.wang@...ux.alibaba.com>,  Ryan
 Roberts <ryan.roberts@....com>,  Yang Shi <yang@...amperecomputing.com>,
  "Christoph Lameter (Ampere)" <cl@...two.org>,  Dev Jain
 <dev.jain@....com>,  Anshuman Khandual <anshuman.khandual@....com>,
  Yicong Yang <yangyicong@...ilicon.com>,  Kefeng Wang
 <wangkefeng.wang@...wei.com>,  Kevin Brodsky <kevin.brodsky@....com>,  Yin
 Fengwei <fengwei_yin@...ux.alibaba.com>,
  linux-arm-kernel@...ts.infradead.org,  linux-kernel@...r.kernel.org,
  linux-mm@...ck.org
Subject: Re: [PATCH -v2 2/2] arm64, tlbflush: don't TLBI broadcast if page
 reused in write fault

Barry Song <21cnbao@...il.com> writes:

>> >
>> > static inline void __flush_tlb_page_nosync(struct mm_struct *mm,
>> >                                            unsigned long uaddr)
>> > {
>> >         unsigned long addr;
>> >
>> >         dsb(ishst);
>> >         addr = __TLBI_VADDR(uaddr, ASID(mm));
>> >         __tlbi(vale1is, addr);
>> >         __tlbi_user(vale1is, addr);
>> >         mmu_notifier_arch_invalidate_secondary_tlbs(mm, uaddr & PAGE_MASK,
>> >                                                 (uaddr & PAGE_MASK) +
>> > PAGE_SIZE);
>> > }
>>
>> IIUC, _nosync() here means doesn't synchronize with the following code.
>> It still synchronizes with the previous code, mainly the page table
>> changing.  And, Yes.  There may be room to improve this.
>>
>> > On the other hand, __ptep_set_access_flags() doesn’t seem to use
>> > set_ptes(), so there’s no guarantee the updated PTEs are visible to all
>> > cores. If a remote CPU later encounters a page fault and performs a TLB
>> > invalidation, will it still see a stable PTE?
>>
>> I don't think so.  We just flush local TLB in local_flush_tlb_page()
>> family functions.  So, we only needs to guarantee the page table changes
>> are available for the local page table walking.  If a page fault occurs
>> on a remote CPU, we will call local_flush_tlb_page() on the remote CPU.
>>
>
> My concern is that:
>
> We don’t have a dsb(ish) to ensure the PTE page table is visible to remote
> CPUs, since you’re using dsb(nsh). So even if a remote CPU performs
> local_flush_tlb_page(), the memory may not be synchronized yet, and it could
> still see the old PTE.

So, do you think that after the load/store unit of the remote CPU have
seen the new PTE, the page table walker could still see the old PTE?  I
doubt it.  Even if so, the worse case is one extra spurious page fault?
If the possibility of the worst case is low enough, that should be OK.

Additionally, the page table lock is held when writing PTE on this CPU
and re-reading PTE on the remote CPU.  That provides some memory order
guarantee too.

---
Best Regards,
Huang, Ying