From: David Hildenbrand <david@redhat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Charan Teja Kalla <quic_charante@quicinc.com>,
akpm@linux-foundation.org, shikemeng@huaweicloud.com,
kasong@tencent.com, nphamcs@gmail.com, bhe@redhat.com,
baohua@kernel.org, chrisl@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH] mm: swap: check for xa_zero_entry() on vma in swapoff path
Date: Mon, 11 Aug 2025 15:19:53 +0200 [thread overview]
Message-ID: <7e7bfd05-434c-40b7-98ec-8ce352a8147d@redhat.com> (raw)
In-Reply-To: <904f85d0-acd6-4f47-ab45-fbf18b80f1c6@lucifer.local>
>>>
>>>> When registering vmas for uprobe, skip the vmas in an mm that is marked
>>>> unstable. Modifying a vma in an unstable mm may cause issues if the mm
>>>> isn't fully initialised.__
>>>>
>>>>> Is there anything preventing us from just leaving a proper tree that
>>>>> reflects reality in place before we drop the write lock?
>>>>
>>>> When you mean proper tree, is this about the your previous question? --
>>>> Shouldn't we just remove anything from the tree here that was not copied
>>>> immediately?
>>>
>>> Commit d24062914837 (" fork: use __mt_dup() to duplicate maple tree in
>>> dup_mmap()") did this for efficiency, so it'd be a regression to do this.
>>
>> We're talking about the case where fork *fails*. That cannot possibly be
>> relevant for performance, can it? :)
>
> I think it optimises the overall operation, but as a product of that, has to
> handle this edge case, and that necessitated this rather horrble stuff.
>
> Obviously we don't need to optimise a 'we are about to die' case :)
Right, so my original question was whether we could just drop all stale
stuff from the tree before we lift the mmap write lock, leaving only the
VMAs in there that we actually processed successfully.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-08-11 13:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 9:21 [PATCH] mm: swap: check for xa_zero_entry() on vma in swapoff path Charan Teja Kalla
2025-08-08 12:01 ` David Hildenbrand
2025-08-08 12:04 ` David Hildenbrand
2025-08-11 9:43 ` Charan Teja Kalla
2025-08-11 12:14 ` Lorenzo Stoakes
2025-08-11 13:03 ` David Hildenbrand
2025-08-11 13:08 ` Lorenzo Stoakes
2025-08-11 13:19 ` David Hildenbrand [this message]
2025-08-11 13:22 ` Lorenzo Stoakes
2025-08-11 15:17 ` Liam R. Howlett
2025-08-11 15:39 ` David Hildenbrand
2025-08-11 15:48 ` Lorenzo Stoakes
2025-08-11 15:51 ` David Hildenbrand
2025-08-11 15:48 ` Liam R. Howlett
2025-08-11 12:07 ` Lorenzo Stoakes
2025-08-11 16:29 ` Charan Teja Kalla
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=7e7bfd05-434c-40b7-98ec-8ce352a8147d@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=nphamcs@gmail.com \
--cc=quic_charante@quicinc.com \
--cc=shikemeng@huaweicloud.com \
--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;
as well as URLs for NNTP newsgroup(s).