From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH mm] vmalloc: back off when the current task is OOM-killed Date: Tue, 21 Sep 2021 11:55:23 -0700 Message-ID: <20210921115523.8606cea0b2f0a5ca4e79cbd0@linux-foundation.org> References: <20210919163126.431674722b8db218453dc18c@linux-foundation.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1632250524; bh=4nfKbEEvnuIK73VTBrjV7lsPLdW7d5cR0/3cZDpflDE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XQ+uwo9Ce+qeUe704wH19OCWWpxZTbGGZupNJ9QAWTxokV6Pl54kFG8CGUjfSin5P 2qTK4wVyhoeLepL7/wCyWf9SYbghTbeZ9lU9z7iIS+ZxtmF1wiEpq6H4d9beaaP3bG FCxw6qzVjGkphbM53CO0re/aquN3en7e4TUSt7NY= In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Vasily Averin Cc: Tetsuo Handa , Michal Hocko , Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org, "Uladzislau Rezki (Sony)" On Mon, 20 Sep 2021 13:59:35 +0300 Vasily Averin wrote: > On 9/20/21 4:22 AM, Tetsuo Handa wrote: > > On 2021/09/20 8:31, Andrew Morton wrote: > >> On Fri, 17 Sep 2021 11:06:49 +0300 Vasily Averin wrote: > >> > >>> Huge vmalloc allocation on heavy loaded node can lead to a global > >>> memory shortage. A task called vmalloc can have the worst badness > >>> and be chosen by OOM-killer, however received fatal signal and > >>> oom victim mark does not interrupt allocation cycle. Vmalloc will > >>> continue allocating pages over and over again, exacerbating the crisis > >>> and consuming the memory freed up by another killed tasks. > >>> > >>> This patch allows OOM-killer to break vmalloc cycle, makes OOM more > >>> effective and avoid host panic. > >>> > >>> Unfortunately it is not 100% safe. Previous attempt to break vmalloc > >>> cycle was reverted by commit b8c8a338f75e ("Revert "vmalloc: back off when > >>> the current task is killed"") due to some vmalloc callers did not handled > >>> failures properly. Found issues was resolved, however, there may > >>> be other similar places. > >> > >> Well that was lame of us. > >> > >> I believe that at least one of the kernel testbots can utilize fault > >> injection. If we were to wire up vmalloc (as we have done with slab > >> and pagealloc) then this will help to locate such buggy vmalloc callers. > > Andrew, could you please clarify how we can do it? > Do you mean we can use exsiting allocation fault injection infrastructure to trigger > such kind of issues? Unfortunately I found no ways to reach this goal. > It allows to emulate single faults with small probability, however it is not enough, > we need to completely disable all vmalloc allocations. I don't see why there's a problem? You're saying "there might still be vmalloc() callers which don't correctly handle allocation failures", yes? I'm suggesting that we use fault injection to cause a small proportion of vmalloc() calls to artificially fail, so such buggy callers will eventually be found and fixed. Why does such a scheme require that *all* vmalloc() calls fail?