From: David Hildenbrand <david@redhat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Jann Horn <jannh@google.com>
Cc: "Uschakow, Stanislav" <suschako@amazon.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"trix@redhat.com" <trix@redhat.com>,
"ndesaulniers@google.com" <ndesaulniers@google.com>,
"nathan@kernel.org" <nathan@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"muchun.song@linux.dev" <muchun.song@linux.dev>,
"mike.kravetz@oracle.com" <mike.kravetz@oracle.com>,
"liam.howlett@oracle.com" <liam.howlett@oracle.com>,
"osalvador@suse.de" <osalvador@suse.de>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: Bug: Performance regression in 1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
Date: Mon, 20 Oct 2025 19:18:18 +0200 [thread overview]
Message-ID: <c81dcb7e-f91c-44e9-b880-0e0188a8ff5b@redhat.com> (raw)
In-Reply-To: <81d096fb-f2c2-4b26-ab1b-486001ee2cac@lucifer.local>
>>>
>>> So in case the page table got reused in the meantime, we should just
>>> back off and be fine, right?
>>
>> The shared page table is mapped with a PUD entry, and we don't check
>> whether the PUD entry changed here.
>
> Could we simply put a PUD check in there sensibly?
A PUD check would only work if we are guaranteed that the page table
will not get freed in the meantime, otherwise we might be walking
garbage, trying to interpret garbage as PMDs etc.
That would require RCU freeing of page tables, which we are not
guaranteed to have IIRC.
The easiest approach is probably to simply never reuse shared page tables.
If there is consensus on that I can try to see if I can make it fly easily.
--
Cheers
David / dhildenb
next prev parent reply other threads:[~2025-10-20 17:18 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 14:30 Uschakow, Stanislav
2025-09-01 10:58 ` Jann Horn
2025-09-01 11:26 ` David Hildenbrand
2025-09-04 12:39 ` Uschakow, Stanislav
2025-10-08 22:54 ` Prakash Sangappa
2025-10-09 7:23 ` David Hildenbrand
2025-10-09 15:06 ` Prakash Sangappa
2025-10-09 7:40 ` David Hildenbrand
2025-10-09 8:19 ` David Hildenbrand
2025-10-16 9:21 ` Lorenzo Stoakes
2025-10-16 19:13 ` David Hildenbrand
2025-10-16 18:44 ` Jann Horn
2025-10-16 19:10 ` David Hildenbrand
2025-10-16 19:26 ` Jann Horn
2025-10-16 19:44 ` David Hildenbrand
2025-10-16 20:25 ` Jann Horn
2025-10-20 15:00 ` Lorenzo Stoakes
2025-10-20 15:33 ` Jann Horn
2025-10-24 12:24 ` Lorenzo Stoakes
2025-10-24 18:22 ` Jann Horn
2025-10-24 19:02 ` Lorenzo Stoakes
2025-10-24 19:43 ` Jann Horn
2025-10-24 19:58 ` Lorenzo Stoakes
2025-10-24 21:41 ` Jann Horn
2025-10-29 16:19 ` David Hildenbrand
2025-10-29 18:02 ` Lorenzo Stoakes
2025-11-18 10:03 ` David Hildenbrand (Red Hat)
2025-11-19 16:08 ` Lorenzo Stoakes
2025-11-19 16:29 ` David Hildenbrand (Red Hat)
2025-11-19 16:31 ` David Hildenbrand (Red Hat)
2025-11-20 15:47 ` David Hildenbrand (Red Hat)
2025-12-03 17:22 ` Prakash Sangappa
2025-12-03 19:45 ` David Hildenbrand (Red Hat)
2025-10-20 17:18 ` David Hildenbrand [this message]
2025-10-24 9:59 ` Lorenzo Stoakes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c81dcb7e-f91c-44e9-b880-0e0188a8ff5b@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=liam.howlett@oracle.com \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=osalvador@suse.de \
--cc=stable@vger.kernel.org \
--cc=suschako@amazon.de \
--cc=trix@redhat.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox