Re: [RFC 3/3] mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag

[Michal Hocko <mhocko@suse.com>]

On Thu 23-04-26 16:43:48, Minchan Kim wrote:
> On Thu, Apr 23, 2026 at 09:17:39AM +0200, Michal Hocko wrote:
> > On Mon 20-04-26 14:47:04, Minchan Kim wrote:
> > > On Fri, Apr 17, 2026 at 09:04:31AM +0200, Michal Hocko wrote:
> > > > On Thu 16-04-26 23:30:09, Minchan Kim wrote:
> > > > > If I send the SIGKILL first to satisfy the process_mrelease() requirement,
> > > > > we immediately run into the scheduling race condition where the victim can
> > > > > enter the exit path before the reaper can set the flag.
> > > > 
> > > > Why don't you just grab the mm before you send the signal and then continue
> > > > with reaping? You just want to avoid a race where the victim manages to
> > > > process fatal signal, start its exit path and mrelease path losing that
> > > > race so you rely on the exit path, right?
> > > 
> > > The problem is that process_mrelease() operates on a task obtained from a pidfd.
> > > 
> > > Once the victim process receives the SIGKILL and enters the exit path (exit_mm),
> > > the kernel sets task->mm to NULL.
> > > 
> > > Even if we could somehow hold a reference to the mm_struct beforehand,
> > > process_mrelease() would still fail because mm_struct via task returns NULL
> > > after exit_mm() has been called.
> > > 
> > > Therefore, we cannot simply "grab the mm" before sending the signal and expect
> > > process_mrelease() to work after the victim starts exiting.
> > 
> > I do not follow. Why cannot you simply do this
> 
> I misunderstood your point. Do you mean this?
> 
> https://lore.kernel.org/linux-mm/20260421230239.172582-4-minchan@kernel.org/
> 
> There are more details to figure out.

Yes, there are couple of details to iron out. The existing
reaping has some hard requirements in place. I am all for relaxing those
where possible (ideally without much of special casing for this specific
use case) but this is much more viable solution than KILL_MRELEASE you
are introducing here. Keep in mind that fundamentally this should be a
really as simple as trigger exit_mmap after sending SIGKILL. We are
reusing a large part of oom_reaper functionality because it was
comfortable but if there are constrains that stand in the way and they
make no sense for this usecase then do not sick with them.
-- 
Michal Hocko
SUSE Labs