linux-kernel - Re: Bug: Performance regression in 1013af4f585f: mm/hugetlb: fix huge_pmd

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>] [day] [month] [year] [list]

Message-ID: <355102b559a747fe9a09142d46852551@amazon.de>
Date: Thu, 4 Sep 2025 12:39:07 +0000
From: "Uschakow, Stanislav" <suschako@...zon.de>
To: David Hildenbrand <david@...hat.com>, Jann Horn <jannh@...gle.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>, "trix@...hat.com"
	<trix@...hat.com>, "ndesaulniers@...gle.com" <ndesaulniers@...gle.com>,
	"nathan@...nel.org" <nathan@...nel.org>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "muchun.song@...ux.dev" <muchun.song@...ux.dev>,
	"mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
	"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
	"liam.howlett@...cle.com" <liam.howlett@...cle.com>, "osalvador@...e.de"
	<osalvador@...e.de>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Bug: Performance regression in 1013af4f585f: mm/hugetlb: fix
 huge_pmd_unshare() vs GUP-fast race

Hi David,

> From: David Hildenbrand <david@...hat.com>
> Sent: Monday, September 1, 2025 1:26 PM
> To: Jann Horn; Uschakow, Stanislav
> Cc: linux-mm@...ck.org; trix@...hat.com; ndesaulniers@...gle.com; nathan@...nel.org; akpm@...ux-foundation.org; muchun.song@...ux.dev; mike.kravetz@...cle.com; lorenzo.stoakes@...cle.com; liam.howlett@...cle.com; osalvador@...e.de; vbabka@...e.cz; stable@...r.kernel.org
> Subject: RE: [EXTERNAL] Bug: Performance regression in 1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
>     
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On 01.09.25 12:58, Jann Horn wrote:
> > Hi!
> >
> > On Fri, Aug 29, 2025 at 4:30 PM Uschakow, Stanislav <suschako@...zon.de> wrote:
> >> We have observed a huge latency increase using `fork()` after ingesting the CVE-2025-38085 fix which leads to the commit `1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race`. On large machines with 1.5TB of memory with 196 cores, we identified  mmapping of 1.2TB of shared memory and forking itself dozens or hundreds of times we see a increase of execution times of a factor of 4. The reproducer is at the end of the email.
> >
> > Yeah, every 1G virtual address range you unshare on unmap will do an
> > extra synchronous IPI broadcast to all CPU cores, so it's not very
> > surprising that doing this would be a bit slow on a machine with 196
> > cores.
> 
> What is the use case for this extreme usage of fork() in that context?
> Is it just something people noticed and it's suboptimal, or is this a
> real problem for some use cases?
> 

Yes, we have customer reporting huge performance regressions on their workloads. I don't know the software architecture or actual use case for their application though. A execution time increase of at least a factor of 4 is noticeable even with few forks() on those machines.

> --
> Cheers
> 
> David / dhildenb


Thanks

Stanislav

    



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597