linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	David Rientjes <rientjes@google.com>,
	Vladimir Davydov <vdavydov@parallels.com>
Subject: Re: [RFC PATCH 5/6] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost
Date: Thu, 7 Jul 2016 10:39:33 +0200	[thread overview]
Message-ID: <20160707083932.GD5379@dhcp22.suse.cz> (raw)
In-Reply-To: <20160703140904.GA26908@redhat.com>

On Sun 03-07-16 17:09:04, Michael S. Tsirkin wrote:
[...]
> Having said all that, how about we just add some kind of per-mm
> notifier list, and let vhost know that owner is going away so
> it should stop looking at memory?

But this would have to be a synchronous operation from the oom killer,
no? I would really like to reduce the number of external dependencies
from the oom killer paths as much as possible. This is the whole point
of these patches. If we have a notification mechanism, what would
guarantee that the oom killer would make a forward progress if the
notified end cannot continue (wait for a lock etc...)?

I do realize that a test per each memory access is not welcome that
much. An alternative would be to hook the check into the page fault
handler because then the overhead would be reduced only to the slowpath
(from the copy_from_user POV). But then also non use_mm users would have
to pay the price which is even less attractive.

Another alternative would be disabling pagefaults when copying from the
userspace. This would require that the memory is prefault when used
which might be a problem for the current implementation.
-- 
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>

  parent reply	other threads:[~2016-07-07  8:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-01  9:26 [RFC PATCH 0/6] fortify oom killer even more Michal Hocko
2016-07-01  9:26 ` [RFC PATCH 1/6] oom: keep mm of the killed task available Michal Hocko
2016-07-03  2:45   ` Tetsuo Handa
2016-07-07  8:24     ` Michal Hocko
2016-07-07 11:48       ` Tetsuo Handa
2016-07-07 13:32         ` Michal Hocko
2016-07-01  9:26 ` [RFC PATCH 2/6] oom, suspend: fix oom_killer_disable vs. pm suspend properly Michal Hocko
2016-07-01  9:26 ` [RFC PATCH 3/6] exit, oom: postpone exit_oom_victim to later Michal Hocko
2016-07-01  9:26 ` [RFC PATCH 4/6] oom, oom_reaper: consider mmget_not_zero as a failure Michal Hocko
2016-07-01  9:26 ` [RFC PATCH 5/6] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost Michal Hocko
2016-07-03 13:47   ` Oleg Nesterov
2016-07-03 14:09     ` Michael S. Tsirkin
2016-07-03 15:18       ` Oleg Nesterov
2016-07-03 15:30         ` Michael S. Tsirkin
2016-07-03 16:47           ` Oleg Nesterov
2016-07-03 21:17             ` Michael S. Tsirkin
2016-07-07  8:28               ` Michal Hocko
2016-07-07 15:38                 ` Michael S. Tsirkin
2016-07-08 12:29                   ` Oleg Nesterov
2016-07-11 14:14                     ` Michal Hocko
2016-07-12 14:33                       ` Oleg Nesterov
2016-07-07  8:42         ` Michal Hocko
2016-07-07 16:46           ` Oleg Nesterov
2016-07-07  8:39       ` Michal Hocko [this message]
2016-07-22 11:09         ` Michal Hocko
2016-07-01  9:26 ` [RFC PATCH 6/6] oom, oom_reaper: allow to reap mm shared by the kthreads Michal Hocko

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=20160707083932.GD5379@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mst@redhat.com \
    --cc=oleg@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --cc=vdavydov@parallels.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