linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: hannes@cmpxchg.org, akpm@linux-foundation.org,
	alan@llwyncelyn.cymru, hch@lst.de, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] vmalloc: back off only when the current task is OOM killed
Date: Tue, 10 Oct 2017 13:54:36 +0200	[thread overview]
Message-ID: <20171010115436.nzgo4ewodx5pyrw7@dhcp22.suse.cz> (raw)
In-Reply-To: <1507633133-5720-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>

On Tue 10-10-17 19:58:53, Tetsuo Handa wrote:
> Commit 5d17a73a2ebeb8d1 ("vmalloc: back off when the current task is
> killed") revealed two bugs [1] [2] that were not ready to fail vmalloc()
> upon SIGKILL. But since the intent of that commit was to avoid unlimited
> access to memory reserves, we should have checked tsk_is_oom_victim()
> rather than fatal_signal_pending().
> 
> Note that even with commit cd04ae1e2dc8e365 ("mm, oom: do not rely on
> TIF_MEMDIE for memory reserves access"), it is possible to trigger
> "complete depletion of memory reserves"

How would that be possible? OOM victims are not allowed to consume whole
reserves and the vmalloc context would have to do something utterly
wrong like PF_MEMALLOC to make this happen. Protecting from such a code
is simply pointless.

> and "extra OOM kills due to depletion of memory reserves"

and this is simply the case for the most vmalloc allocations because
they are not reflected in the oom selection so if there is a massive
vmalloc consumer it is very likely that we will kill a large part the
userspace before hitting the user context on behalf which the vmalloc
allocation is performed.

I have tried to explain this is not really needed before but you keep
insisting which is highly annoying. The patch as is is not harmful but
it is simply _pointless_ IMHO.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-10-10 11:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-10 10:58 Tetsuo Handa
2017-10-10 11:54 ` Michal Hocko [this message]
2017-10-10 12:47   ` Tetsuo Handa
2017-10-10 13:49     ` Michal Hocko
2017-10-10 14:13       ` Tetsuo Handa
2017-10-10 14:17         ` Michal Hocko
2017-10-10 12:47 ` Johannes Weiner

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=20171010115436.nzgo4ewodx5pyrw7@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alan@llwyncelyn.cymru \
    --cc=hannes@cmpxchg.org \
    --cc=hch@lst.de \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    /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