From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Liam R. Howlett" <liam@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>, Minchan Kim <minchan@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
akpm@linux-foundation.org, hca@linux.ibm.com,
linux-s390@vger.kernel.org, brauner@kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
timmurray@google.com, "Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: Re: [PATCH v1 2/3] mm: process_mrelease: skip LRU movement for exclusive file folios
Date: Mon, 11 May 2026 15:05:44 +0200 [thread overview]
Message-ID: <4df23f32-c538-4755-a1c9-be8559a103a3@kernel.org> (raw)
In-Reply-To: <7g5g57jbll5joujbwjb4osqhdwqd4yzc54wmoi7ftx4a4chuax@xtxyljtqaodp>
>>
>> But we'd have to learn from Liam :)
>
> Yes, it will be a zero entry tree now.
>
> I left the flag to indicate that it's an unstable mm, not for faulting
> in but to be skipped in OOM events and process_mrelease since neither
> should bother doing anything in the window between the dup_mm() failure
> and the exit_mmap() window where the write lock was dropped.
>
> We can safely drop the flag now if you want to, because everything has
> to deal with an empty vma tree anyways - a race can occur between a call
> to unmap everything and the task seg faulting.
Thanks for confirming!
>
>>
>>
>>>
>>> The bottom line is the same. Make sure PF fails rather than silently
>>> provide potentially corrupted data.
>>>
>>>
>>> Ohh, you mean to add a new flag, right?
>>
>> We could do that as well, if it's of any help.
>
> I really think this goes back to the life cycle of the mm being somewhat
> difficult to figure out.
Agreed.
> I'm fine with another flag.
Right, alternatively we could just turn the unstable flag into a "OOM is hiding
in the bushes to reap this MM".
--
Cheers,
David
next prev parent reply other threads:[~2026-05-11 13:05 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 23:02 [PATCH v1 0/3] mm: process_mrelease: expedite clean file folio reclaim and add auto-kill Minchan Kim
2026-04-21 23:02 ` [PATCH v1 1/3] mm: process_mrelease: expedite clean file folio reclaim via mmu_gather Minchan Kim
2026-04-24 7:56 ` David Hildenbrand (Arm)
2026-04-24 21:24 ` Minchan Kim
2026-04-27 9:29 ` David Hildenbrand (Arm)
2026-04-27 22:04 ` Minchan Kim
2026-04-24 19:33 ` Matthew Wilcox
2026-04-24 21:56 ` Minchan Kim
2026-05-05 14:53 ` Alexander Gordeev
2026-05-08 21:56 ` Minchan Kim
2026-05-11 16:13 ` Alexander Gordeev
2026-05-11 21:48 ` Minchan Kim
2026-04-21 23:02 ` [PATCH v1 2/3] mm: process_mrelease: skip LRU movement for exclusive file folios Minchan Kim
2026-04-22 7:22 ` Baolin Wang
2026-04-23 23:38 ` Minchan Kim
2026-04-24 7:51 ` Michal Hocko
2026-04-24 7:57 ` David Hildenbrand (Arm)
2026-04-24 19:15 ` Minchan Kim
2026-04-27 7:16 ` Michal Hocko
2026-04-27 16:48 ` Suren Baghdasaryan
2026-04-27 17:15 ` Michal Hocko
2026-04-27 23:05 ` Minchan Kim
2026-04-28 6:56 ` Michal Hocko
2026-04-29 1:19 ` Minchan Kim
2026-04-29 8:18 ` Michal Hocko
2026-04-29 9:09 ` David Hildenbrand (Arm)
2026-04-29 10:33 ` Michal Hocko
2026-04-29 13:07 ` David Hildenbrand (Arm)
2026-04-29 14:44 ` Michal Hocko
2026-04-30 6:08 ` David Hildenbrand (Arm)
2026-05-08 20:57 ` Liam R. Howlett
2026-05-11 13:05 ` David Hildenbrand (Arm) [this message]
2026-05-13 6:47 ` Michal Hocko
2026-04-29 21:41 ` Minchan Kim
2026-04-30 14:38 ` David Hildenbrand (Arm)
2026-04-29 8:55 ` David Hildenbrand (Arm)
2026-04-29 21:42 ` Minchan Kim
2026-04-24 19:26 ` Minchan Kim
2026-04-21 23:02 ` [PATCH v1 3/3] mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag Minchan Kim
2026-04-24 7:57 ` Michal Hocko
2026-04-24 22:49 ` Minchan Kim
2026-04-27 7:02 ` Michal Hocko
2026-04-27 22:03 ` Minchan Kim
2026-04-28 7:01 ` Michal Hocko
2026-04-28 22:37 ` Minchan Kim
2026-04-29 8:25 ` Michal Hocko
2026-04-29 20:01 ` Suren Baghdasaryan
2026-04-29 21:17 ` Minchan Kim
2026-04-29 21:16 ` Minchan Kim
2026-04-27 20:34 ` Suren Baghdasaryan
2026-04-27 22:52 ` Minchan Kim
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=4df23f32-c538-4755-a1c9-be8559a103a3@kernel.org \
--to=david@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=hca@linux.ibm.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=surenb@google.com \
--cc=timmurray@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.