linux-kernel - Re: [PATCH v2] mmu_gather: move tlb flush for VM_PFNMAP/VM_MIXEDMAP vmas into free

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: <20250124083139.GB13226@noisy.programming.kicks-ass.net>
Date: Fri, 24 Jan 2025 09:31:39 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Hugh Dickins <hughd@...gle.com>
Cc: Jann Horn <jannh@...gle.com>, Roman Gushchin <roman.gushchin@...ux.dev>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Will Deacon <will@...nel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
	Nick Piggin <npiggin@...il.com>, linux-arch@...r.kernel.org
Subject: Re: [PATCH v2] mmu_gather: move tlb flush for VM_PFNMAP/VM_MIXEDMAP
 vmas into free_pgtables()

On Thu, Jan 23, 2025 at 08:42:36PM -0800, Hugh Dickins wrote:
> The changelog of commit b67fbebd4cf9 ("mmu_gather: Force tlb-flush
> VM_PFNMAP vmas") has not helped me either.  Nor could I locate any
> discussion (Jann, Linus, Peter, Will?) that led up to it.

Hmm, that was probably on security -- I should have those mails around
somewhere, I'll see if I can dig them up.

> To me, Peter's patch looks much like yours, except wth different
> names and comments, plus the "vma" error you point out below.

Yes, 3 differences:

 - naming;
 - the extra check;
 - the vma_pfn clearing condition.

Under the assumption that this is all about those PFNs, the argument
(as also outlined in the email to Roman just now) is that you only need
to flush if both: you have pending TLBI for PFN and are indeed about to
unlink a PFN vma.

If we've flushed the relevant PFNs earlier, for whatever reason,
batching, or the arch has !MERGE_VMAS or whatever, then we do not need
to flush again. So clearing vma_pfn in __tlb_reset_range() is the right
place.

Similarly, if we don't ever actually free/unlink the PFN vma, we also
don't care.