Re: [PATCH v1 3/3] mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag

Michal Hocko
2026-04-27T07:02:47Z

On Fri 24-04-26 15:49:19, Minchan Kim wrote:
> On Fri, Apr 24, 2026 at 09:57:20AM +0200, Michal Hocko wrote:
> > On Tue 21-04-26 16:02:39, Minchan Kim wrote:
> > > Currently, process_mrelease() requires userspace to send a SIGKILL signal
> > > prior to the call. This separation introduces a scheduling race window
> > > where the victim task may receive the signal and enter the exit path
> > > before the reaper can invoke process_mrelease().
> > >
> > > When the victim enters the exit path (do_exit -> exit_mm), it clears its
> > > task->mm immediately. This causes process_mrelease() to fail with -ESRCH,
> > > leaving the actual address space teardown (exit_mmap) to be deferred until
> > > the mm's reference count drops to zero. In Android, arbitrary reference counts
> > > (e.g., async I/O, reading /proc/<pid>/cmdline, or various other remote
> > > VM accesses) frequently delay this teardown indefinitely, defeating the
> > > purpose of expedited reclamation.
> > >
> > > This delay keeps memory pressure high, forcing the system to unnecessarily
> > > kill additional innocent background apps before the memory from the first
> > > victim is recovered.
> >
> > Thanks, this makes the motivation much more clear and usecase very
> > sound.
> >
> > > This patch introduces the PROCESS_MRELEASE_REAP_KILL UAPI flag to support
> > > an integrated auto-kill mode. When specified, process_mrelease() directly
> > > injects a SIGKILL into the target task.
> > >
> > > To solve the race condition deterministically, we grab the mm reference
> > > via mmget() and set the MMF_UNSTABLE flag *before* sending the SIGKILL.
> > > Using mmget() instead of mmgrab() keeps mm_users > 0, preventing the
> > > victim from calling exit_mmap() in its own exit path.
> >
> > Why is this needed? Address space tear down is an operation that can run
> > from several execution contexts.
>
> Agreed.
>
> >
> > > This ensures that
> > > the memory is reclaimed synchronously and deterministically by the reaper
> > > in the context of process_mrelease(), avoiding delays caused by
> > > non-deterministic scheduling of the victim task.
> >
> > The memory is still reclaimed synchronously from the mrelease context.
> > This is really confusing.
> >
> > Please also explain why do you need to do all that ugly
> > task_will_free_mem hoops. Why cannot you simply kill the task if
> > task_will_free_mem fails (if PROCESS_MRELEASE_REAP_KILL is used).
>
> I wanted to handle shared address spaces.
> Even though we are okay with the target task not being in a SIGKILL
> state yet (since we are about to kill it), we must ensure that all
> *other* processes sharing the same mm are also dying.

Then just bail out when the mm is shared accross thread groups, rather
than kill just one of them. Or kill all of them. There is no reason to
play around that on the task_will_free_mem level.
--
Michal Hocko
SUSE Labs