mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Alexis Bouzigues <BouziguesAlexis@johndeere.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: nommu: set MMF_OOM_SKIP in exit_mmap()
Date: Mon, 19 Oct 2026 10:05:59 +0200	[thread overview]
Message-ID: <atXPZ4QB7qoCt3di@tiehlicka> (raw)
In-Reply-To: <BY3PR05MB8260C9F9055EB094183544A9A09A2@BY3PR05MB8260.namprd05.prod.outlook.com>

On Sat 17-10-26 04:32:37, Alexis Bouzigues wrote:
> On Fri, Oct 16, 2026 at 08:54:56AM +0200, Michal Hocko wrote:
> > Correct. The question is why killing the child, which has passed
> > exit_mmap stage sucessfully didn't help.
> 
> There needs to be ongoing memory pressure otherwise the
> parent's allocation succeeds and does not hit oom_kill.c or a livelock.
> 
> If there is memory pressure, then the allocation hits out_of_memory() and
> then blocked in the __alloc_pages_slowpath/oom_evaluate_task retry loop.
> 
> > a) a corner case of a valid nommu application or this is
> >    a theoretical problem
> 
> I think it is mainly a correctness fix (see below). I have only hit it
> with benchmarks, including the /init provided earlier from which I obtained
> the backtrace. I encountered this bug initially while running a
> benchmark to test memory reductions.

Make sure you describe this in the changelog. Along with an explanation
why this benchmakr matters or represent any real life scenario.
Especially in the context of how oom situation on nommu is inherently
fragile.

> > b) why this doesn't break otherwise very fragile nommu oom
> >    handling
> 
> It does not break nommu oom handling because it places the flag only in
> exit_mmap() right after the process has called the last delete_vma,
> guaranteeing it has freed all of its private memory.
> 
> This flag is used similarly on mmu (mmap.c) and in previous versions of
> nommu, until the Fixes tag 212925802454 ("mm: oom: let oom_reap_task
> and exit_mmap run concurrently"). It took it away from the shared
> __mmput() and only kept it in the mmu-only path (exit_mmap of
> mm/mmap.c).
> 
>   void exit_mmap(struct mm_struct *mm)
>   {
>           ...
>           unmap_vmas(&tlb, &unmap);
>           mmap_read_unlock(mm);
> 
>           /*
>            * Set MMF_OOM_SKIP to hide this task from the oom killer/reaper
>            * because the memory has been already freed.
>            */
>           mm_flags_set(MMF_OOM_SKIP, mm);
>           ...
> 
> This change places it in the same exit_mmap() of nommu.c.
> 
> The MMF_OOM_SKIP mm flag comes from your commit a while ago
> 862e3073b3ee ("mm, oom: get rid of signal_struct::oom_victims") and had
> the same rationale for nommu to mark the pid's mm to hide the process from
> oom killer:
> 
>     After "oom: keep mm of the killed task available" we can safely detect
>     an oom victim by checking task->signal->oom_mm so we do not need the
>     signal_struct counter anymore so let's get rid of it.
> 
>     This alone wouldn't be sufficient for nommu archs because
>     exit_oom_victim doesn't hide the process from the oom killer anymore.
>     We can, however, mark the mm with a MMF flag in __mmput.  We can reuse
>     MMF_OOM_REAPED and rename it to a more generic MMF_OOM_SKIP.
> 
> Let me know if this answers your questions!

Fair enough. And now I see where the Fixes tag came from. This was a
side effect of that change because oom victims are not hidden anymore.
Would be good to clarify that in the changelog.

Thanks
-- 
Michal Hocko
SUSE Labs

      reply	other threads:[~2026-10-19  8:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13 22:56 Alexis Bouzigues via B4 Relay
2026-10-14  7:50 ` Michal Hocko
2026-10-14 21:58   ` Alexis Bouzigues
2026-10-15  7:03     ` Michal Hocko
2026-10-16  0:42       ` Alexis Bouzigues
2026-10-16  6:54         ` Michal Hocko
2026-10-17  4:32           ` Alexis Bouzigues
2026-10-19  8:05             ` Michal Hocko [this message]

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=atXPZ4QB7qoCt3di@tiehlicka \
    --to=mhocko@suse.com \
    --cc=BouziguesAlexis@johndeere.com \
    --cc=akpm@linux-foundation.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.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

all inboxes | Powered by JetHome®