linux-kernel - Re: [PATCH v1 4/4] mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu

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: <e10cf4de-6c00-4ed0-a1d4-d8e719f86a3e@kernel.org>
Date: Thu, 18 Dec 2025 13:52:45 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
 linux-mm@...ck.org, Will Deacon <will@...nel.org>,
 "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>, Nick Piggin <npiggin@...il.com>,
 Peter Zijlstra <peterz@...radead.org>, Arnd Bergmann <arnd@...db.de>,
 Muchun Song <muchun.song@...ux.dev>, Oscar Salvador <osalvador@...e.de>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka
 <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
 Pedro Falcato <pfalcato@...e.de>, Rik van Riel <riel@...riel.com>,
 Harry Yoo <harry.yoo@...cle.com>, Laurence Oberman <loberman@...hat.com>,
 Prakash Sangappa <prakash.sangappa@...cle.com>,
 Nadav Amit <nadav.amit@...il.com>, stable@...r.kernel.org
Subject: Re: [PATCH v1 4/4] mm/hugetlb: fix excessive IPI broadcasts when
 unsharing PMD tables using mmu_gather

>>>
>>> Isn't really the correct comment here that ranges that previously mapped the
>>> shared pages might no longer, so we must clear the TLB? I may be missing
>>> something :)
>>
>> There are cases where we defer flushing the TLB until we dropped all (exclusive) locks.
>> In particular, MADV_DONTNEED does that in some cases, essentially deferring the flush
>> to the tlb_finish_mmu().
>>
>> free_pgtables() will also defer the flush, performing the TLB flush during tlb_finish_mmu(),
>> before
>>
>> The point is (as I tried to make clear in the comment), for unsharing we have no control
>> whenn the page table gets freed after we drop the lock.
>>
>> So we must flush the TLB now and cannot defer it like we do in the other cases.
> 
> Yeah I guess because of the above - that is - other users may unshare for their
> CPUs but not unshare for ours?
Yes :)

It's all very complicated, therefore I decided to rather add more 
comments describing what we depend on.

-- 
Cheers

David