[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84fddb8e-a23b-e970-c8e9-74aa2fe2716d@i-love.sakura.ne.jp>
Date: Thu, 16 Jan 2020 06:09:57 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: David Rientjes <rientjes@...gle.com>
Cc: Michal Hocko <mhocko@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch] mm, oom: dump stack of victim when reaping failed
On 2020/01/16 5:27, David Rientjes wrote:
> I'm
> currently tracking a stall in oom reaping where the victim doesn't always
> have a lock held so we don't know where it's at in the kernel; I'm hoping
> that a stack for the thread group leader will at least shed some light on
> it.
>
This change was already proposed at
https://lore.kernel.org/linux-mm/20180320122818.GL23100@dhcp22.suse.cz/ .
And according to that proposal, it is likely i_mmap_lock_write() in dup_mmap()
in copy_process(). We tried to make that lock killable but we gave it up
because nobody knows whether it is safe to do make it killable.
Powered by blists - more mailing lists