From: Michal Hocko <mhocko@suse.com>
To: Jiayuan Chen <jiayuan.chen@linux.dev>
Cc: linux-mm@kvack.org, Jiayuan Chen <jiayuan.chen@shopee.com>,
Zhou Yingfu <yingfu.zhou@shopee.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
David Rientjes <rientjes@google.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/oom_kill: fix hung tasks queued on mmap_lock behind a long reap
Date: Mon, 14 Sep 2026 20:36:16 +0200 [thread overview]
Message-ID: <aqg-oG2HDIUeK5Us@tiehlicka> (raw)
In-Reply-To: <20260914113239.367200-1-jiayuan.chen@linux.dev>
On Mon 14-09-26 19:32:37, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
>
> The oom reaper holds mmap_lock for read while it unmaps the whole
> victim. Anyone who wants that lock for write in the meantime sits in D
> state until the reap is over.
>
> With swap enabled the victim can be several times the size of RAM and
> the reap runs for minutes. LTP oom01 trips hung_task that way for the
> victim and for ksmd, on 6.6 LTS and on 7.3.0-rc1:
>
> Call Trace:
> <TASK>
> __schedule+0x487/0x1870
> schedule+0x28/0xb0
> schedule_preempt_disabled+0x16/0x30
> rwsem_down_write_slowpath+0x1d4/0x750
> down_write+0x60/0x70
> __ksm_exit+0xb4/0x230
> __mmput+0x12c/0x150
> mmput+0x1e/0x30
> do_exit+0x283/0xa30
> do_group_exit+0x34/0x90
> get_signal+0x952/0x960
> arch_do_signal_or_restart+0x41/0x250
> exit_to_user_mode_loop+0xd3/0x560
> do_syscall_64+0x385/0x470
> </TASK>
>
> KSM is just the one LTP happened to hit: __khugepaged_exit() has the
> same write lock cycle ahead of exit_mmap().
Why is this a practical problem we need to care about? It is kind of
natural that the oom victim exit path might race with the oom reaper. They
share the same lock that is mutualy exclusive. The whole point of the
reaper is to ensure there is a forward progress achieved. So before we
start modifying this let's talk about any practical/real life problems.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2026-09-14 18:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 11:32 Jiayuan Chen
2026-09-14 14:32 ` David Hildenbrand (Arm)
2026-09-14 18:36 ` 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=aqg-oG2HDIUeK5Us@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jiayuan.chen@linux.dev \
--cc=jiayuan.chen@shopee.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=yingfu.zhou@shopee.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 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®