From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
maple-tree@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Vlastimil Babka <vbabka@suse.cz>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Charan Teja Kalla <quic_charante@quicinc.com>,
shikemeng@huaweicloud.com, kasong@tencent.com, nphamcs@gmail.com,
bhe@redhat.com, baohua@kernel.org, chrisl@kernel.org,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [RFC PATCH 4/6] mm/memory: Add tree limit to free_pgtables()
Date: Tue, 9 Sep 2025 13:19:24 -0400 [thread overview]
Message-ID: <gtt62i4wiflnhetv2w4kanbs64z2bdmxhth3hqdz5bcflfamkk@ojhlmqy4r3po> (raw)
In-Reply-To: <a3777992-21fc-4e55-9a5e-72b17dc86135@redhat.com>
* David Hildenbrand <david@redhat.com> [250904 06:21]:
> On 03.09.25 22:19, Liam R. Howlett wrote:
> > * Lorenzo Stoakes <lorenzo.stoakes@oracle.com> [250819 15:14]:
> > > On Fri, Aug 15, 2025 at 03:10:29PM -0400, Liam R. Howlett wrote:
> > > > The ceiling and tree search limit need to be different arguments for the
> > > > future change in the failed fork attempt.
> > > >
> > > > No functional changes intended.
> > > >
> > > > Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> > >
> > > (Obv. in addition to comment about broken VMA tests :P)
> > >
> > > I guess intent is that if we discover any page tables beyond tree_max then
> > > we ought to just wipe them all out so, in effect, we don't consider
> > > mappings at or past tree_max to be valid?
> >
> > Actually... there are some archs that map outside the vma and they are
> > valid.. I think mips? and I think lower, but yeah.. it's needed. This
> > is why prev->vm_end and next->vm_start are used as page table limits,
> > afaik. This is a serious annoyance because it frequently adds walks
> > that are infrequently necessary to the vma tree.
>
> Hm, does that still exist?
I think it does?
arch/mips/mm/fault.c still checks for addresses between VMALLOC_START
and VMALLOC_END, as well as MODULES_VADDR and MODULES_END and
(potentially, depending on CONFIG) jumps to vmalloc_fault.
I tried to find the statement of the start/end going to the next/prev
vma that came across before, but I cannot. It may have been in a git
log for something else entirely.
> I recall something odd ... was it that gate area thingy (in_gate_area) we
> also have to handle in GUP code? The is x86/arm though, not mips.
IIRC, gate area is to do with vdso/vvars and so going to the maximum
allowed pte would unmap that even when it's not in the vma tree - which
it is not. This is true for most platforms.
But if that's the case, then unmapping the last vma in the tree would
cause the vdso to no longer work - which doesn't make sense to me?
I'm not sure if any platform maps them at a low value so that
"prev->vm_start or 0" makes sense, but I would not be surprised.
Thanks,
Liam
next prev parent reply other threads:[~2025-09-09 17:19 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 19:10 [RFC PATCH 0/6] Remove XA_ZERO from error recovery of Liam R. Howlett
2025-08-15 19:10 ` [RFC PATCH 1/6] mm/mmap: Move exit_mmap() trace point Liam R. Howlett
2025-08-19 18:27 ` Lorenzo Stoakes
2025-08-21 21:12 ` Chris Li
2025-08-15 19:10 ` [RFC PATCH 2/6] mm/mmap: Abstract vma clean up from exit_mmap() Liam R. Howlett
2025-08-19 18:38 ` Lorenzo Stoakes
2025-09-03 19:56 ` Liam R. Howlett
2025-09-04 15:21 ` Lorenzo Stoakes
2025-08-15 19:10 ` [RFC PATCH 3/6] mm/vma: Add limits to unmap_region() for vmas Liam R. Howlett
2025-08-19 18:48 ` Lorenzo Stoakes
2025-09-03 19:57 ` Liam R. Howlett
2025-09-04 15:23 ` Lorenzo Stoakes
2025-08-15 19:10 ` [RFC PATCH 4/6] mm/memory: Add tree limit to free_pgtables() Liam R. Howlett
2025-08-18 15:36 ` Lorenzo Stoakes
2025-08-18 15:54 ` Liam R. Howlett
2025-08-19 19:14 ` Lorenzo Stoakes
2025-09-03 20:19 ` Liam R. Howlett
2025-09-04 10:20 ` David Hildenbrand
2025-09-04 15:36 ` Lorenzo Stoakes
2025-09-09 17:19 ` Liam R. Howlett [this message]
2025-09-04 15:33 ` Lorenzo Stoakes
2025-08-15 19:10 ` [RFC PATCH 5/6] mm/vma: Add page table limit to unmap_region() Liam R. Howlett
2025-08-19 19:27 ` Lorenzo Stoakes
2025-08-15 19:10 ` [RFC PATCH 6/6] mm: Change dup_mmap() recovery Liam R. Howlett
2025-08-18 15:12 ` Lorenzo Stoakes
2025-08-18 15:29 ` Lorenzo Stoakes
2025-08-19 20:33 ` Lorenzo Stoakes
2025-09-04 0:13 ` Liam R. Howlett
2025-09-04 15:40 ` Lorenzo Stoakes
2025-08-15 19:49 ` [RFC PATCH 0/6] Remove XA_ZERO from error recovery of Jann Horn
2025-08-18 15:48 ` Liam R. Howlett
2025-08-18 9:44 ` David Hildenbrand
2025-08-18 14:26 ` Charan Teja Kalla
2025-08-18 14:54 ` Liam R. Howlett
2025-08-18 15:47 ` 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=gtt62i4wiflnhetv2w4kanbs64z2bdmxhth3hqdz5bcflfamkk@ojhlmqy4r3po \
--to=liam.howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=jannh@google.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=maple-tree@lists.infradead.org \
--cc=mhocko@suse.com \
--cc=nphamcs@gmail.com \
--cc=pfalcato@suse.de \
--cc=quic_charante@quicinc.com \
--cc=rppt@kernel.org \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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