Re: KVM hang after OOM

From: Michal Hocko <mhocko@kernel.org>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	linux-mm@kvack.org, kvm@vger.kernel.org,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Subject: Re: KVM hang after OOM
Date: Thu, 22 Mar 2018 09:39:07 +0100	[thread overview]
Message-ID: <20180322083907.GC22674@dhcp22.suse.cz> (raw)
In-Reply-To: <CABXGCsNBEpVoMzrhyNLKhzNxPs=9a+Z+2aUxJ8WtZ8gE+=OGSA@mail.gmail.com>

On Thu 22-03-18 02:14:42, Mikhail Gavrilov wrote:
> On 20 March 2018 at 17:20, Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> > Michal Hocko wrote:
> >> On Mon 19-03-18 21:23:12, Mikhail Gavrilov wrote:
> >> > using swap actively.
> >> > But I'm already satisfied with proposed patch.
> >> >
> >> > I am attached dmesg when I triggering OOM three times. And every time
> >> > after it system survived.
> >> > I think this patch should be merged in mainline.
> >>
> >> Could you be more specific what is _this_ patch, please?
> >
> > I think it is
> > "[PATCH] mm/thp: Do not wait for lock_page() in deferred_split_scan()".
> >
> > Unless the problem is something like commit 0b1d647a02c5a1b6
> > ("[PATCH] dm: work around mempool_alloc, bio_alloc_bioset deadlocks"),
> > there should be no need to use io_schedule_timeout().
> >
> > Mikhail, can you test with only
> > "[PATCH] mm/thp: Do not wait for lock_page() in deferred_split_scan()" and
> > "[PATCHv2] mm/shmem: Do not wait for lock_page() in shmem_unused_huge_shrink()"
> > applied? Because the last dmesg.txt was using io_schedule_timeout()...
> 
> 
> This is my fault that I'm not checked firstly fresh 4.16-rc6 (without patches).
> Now I am corrected. I conducted a series of experiments with the fresh
> rc6 kernel (without patches) and with applied mm/thp patch.
> The experiment showed that rc6 does not affected by described in this
> thread issue.
> Virtual machine in KVM not hangs after OOM occured.

OK, I have a suspicion that you have seen more issues triggering
simultaneously. One is a  mmap_sem deadlock reported by lockdep and
followed by VM_WARN_ON_ONCE(fault_flags & FAULT_FLAG_ALLOW_RETRY): mm/gup.c:498
which sounds suspicious on its own. I have quickly glanced through kvm
commits since 4.15 but nothing really jumped at me as a fix.

Then you have seen the lock_page in deferred_split_scan which might or
might not be a deadlock.

Hard to conclude what was the primary issue here. Let's see if the
problem reproduces for you with the current 4.16 kernel.

Thanks!
-- 
Michal Hocko
SUSE Labs