Re: [PATCH 01/13] mm/mmap: free gathered pages before MMF_OOM_SKIP

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Nov 12, 2026 at 11:59:50AM -0500, Gregory Price (Meta) wrote:
> On 2026-11-11 18:13 +0000, Lorenzo Stoakes (ARM) wrote:
> > The OOM killer can quickly trigger again after having selected a
> > victim. That victim might not have freed its memory yet, but its mm will
> > be marked MMF_OOM_SKIP by this point, so the OOM killer will ignore it.
> >
> > This can cause the OOM killer to kill an innocent process when the first
> > might have freed enough memory to relieve the memory pressure.
> >
> > Fix the issue by freeing the memory before marking the mm MMF_OOM_SKIP.
> >
> > Note that the task which calls mmput() might not be the victim - if it
> > took a reference on the mm (e.g. ptrace), it may hold the last reference
> > and release it when it calls mmput().
> >
> > Therefore we cannot rely on current to tell whether the mm belongs to an
> > OOM victim. Instead, partially revert commit b3541d912a84 ("mm: delete
> > unused MMF_OOM_VICTIM flag") to reinstate MMF_OOM_VICTIM, which
> > mark_oom_victim() sets on the victim's mm, and check that.
> >
> > Reported-by: Chris Mason <mason@kernel.org>
> > Fixes: bf3980c85212 ("mm: drop oom code from exit_mmap")
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>
> I was able to reproduce/observe the unfreed batch and the second victim
> issue.  In the base series i could kill a second victim with the
> in-flight oom in about 26/512 attempts, and 0/512 attempts with this
> patch.

This sounds a little like an episode of Dexter but thanks :))

>
> Reviewed-by: Gregory Price (Meta) <gourry@gourry.net>
> Tested-by: Gregory Price (Meta) <gourry@gourry.net>

Appreciated!

--
Cheers, Lorenzo