All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] mm, oom_reaper: skip mm structs with mmu notifiers
Date: Wed, 13 Sep 2017 15:18:30 +0200	[thread overview]
Message-ID: <20170913131830.GA12833@redhat.com> (raw)
In-Reply-To: <20170913113427.2291-1-mhocko@kernel.org>

On Wed, Sep 13, 2017 at 01:34:27PM +0200, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> Andrea has noticed that the oom_reaper doesn't invalidate the range
> via mmu notifiers (mmu_notifier_invalidate_range_start,
> mmu_notifier_invalidate_range_end) and that can corrupt the memory
> of the kvm guest for example.
> 
> tlb_flush_mmu_tlbonly already invokes mmu notifiers but that is not
> sufficient as per Andrea:
> : mmu_notifier_invalidate_range cannot be used in replacement of
> : mmu_notifier_invalidate_range_start/end. For KVM
> : mmu_notifier_invalidate_range is a noop and rightfully so. A MMU
> : notifier implementation has to implement either
> : ->invalidate_range method or the invalidate_range_start/end
> : methods, not both. And if you implement invalidate_range_start/end
> : like KVM is forced to do, calling mmu_notifier_invalidate_range in
> : common code is a noop for KVM.
> :
> : For those MMU notifiers that can get away only implementing
> : ->invalidate_range, the ->invalidate_range is implicitly called by
> : mmu_notifier_invalidate_range_end(). And only those secondary MMUs
> : that share the same pagetable with the primary MMU (like AMD
> : iommuv2) can get away only implementing ->invalidate_range.
> 
> As the callback is allowed to sleep and the implementation is out
> of hand of the MM it is safer to simply bail out if there is an
> mmu notifier registered. In order to not fail too early make the
> mm_has_notifiers check under the oom_lock and have a little nap before
> failing to give the current oom victim some more time to exit.
> 
> Changes since v1
> - move mm_has_notifiers check after we hold mmap_sem to prevent from
>   any potential races as per Andrea
> 
> Fixes: aac453635549 ("mm, oom: introduce oom reaper")
> Noticed-by: Andrea Arcangeli <aarcange@redhat.com>
> Cc: stable
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> Hi,
> I have posted this as an RFC previously [1]. I have updated
> the changelog to be more clear about the issue and moved the
> mm_has_notifiers after the lock has been take based on Andrea's
> suggestion.
> 
> Can we merge this?
> 
> [1] http://lkml.kernel.org/r/20170830084600.17491-1-mhocko@kernel.org
> 
>  include/linux/mmu_notifier.h |  5 +++++
>  mm/oom_kill.c                | 16 ++++++++++++++++
>  2 files changed, 21 insertions(+)

Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Andrea Arcangeli <aarcange@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] mm, oom_reaper: skip mm structs with mmu notifiers
Date: Wed, 13 Sep 2017 15:18:30 +0200	[thread overview]
Message-ID: <20170913131830.GA12833@redhat.com> (raw)
In-Reply-To: <20170913113427.2291-1-mhocko@kernel.org>

On Wed, Sep 13, 2017 at 01:34:27PM +0200, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> Andrea has noticed that the oom_reaper doesn't invalidate the range
> via mmu notifiers (mmu_notifier_invalidate_range_start,
> mmu_notifier_invalidate_range_end) and that can corrupt the memory
> of the kvm guest for example.
> 
> tlb_flush_mmu_tlbonly already invokes mmu notifiers but that is not
> sufficient as per Andrea:
> : mmu_notifier_invalidate_range cannot be used in replacement of
> : mmu_notifier_invalidate_range_start/end. For KVM
> : mmu_notifier_invalidate_range is a noop and rightfully so. A MMU
> : notifier implementation has to implement either
> : ->invalidate_range method or the invalidate_range_start/end
> : methods, not both. And if you implement invalidate_range_start/end
> : like KVM is forced to do, calling mmu_notifier_invalidate_range in
> : common code is a noop for KVM.
> :
> : For those MMU notifiers that can get away only implementing
> : ->invalidate_range, the ->invalidate_range is implicitly called by
> : mmu_notifier_invalidate_range_end(). And only those secondary MMUs
> : that share the same pagetable with the primary MMU (like AMD
> : iommuv2) can get away only implementing ->invalidate_range.
> 
> As the callback is allowed to sleep and the implementation is out
> of hand of the MM it is safer to simply bail out if there is an
> mmu notifier registered. In order to not fail too early make the
> mm_has_notifiers check under the oom_lock and have a little nap before
> failing to give the current oom victim some more time to exit.
> 
> Changes since v1
> - move mm_has_notifiers check after we hold mmap_sem to prevent from
>   any potential races as per Andrea
> 
> Fixes: aac453635549 ("mm, oom: introduce oom reaper")
> Noticed-by: Andrea Arcangeli <aarcange@redhat.com>
> Cc: stable
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> Hi,
> I have posted this as an RFC previously [1]. I have updated
> the changelog to be more clear about the issue and moved the
> mm_has_notifiers after the lock has been take based on Andrea's
> suggestion.
> 
> Can we merge this?
> 
> [1] http://lkml.kernel.org/r/20170830084600.17491-1-mhocko@kernel.org
> 
>  include/linux/mmu_notifier.h |  5 +++++
>  mm/oom_kill.c                | 16 ++++++++++++++++
>  2 files changed, 21 insertions(+)

Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>

  reply	other threads:[~2017-09-13 13:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-13 11:34 [PATCH] mm, oom_reaper: skip mm structs with mmu notifiers Michal Hocko
2017-09-13 11:34 ` Michal Hocko
2017-09-13 13:18 ` Andrea Arcangeli [this message]
2017-09-13 13:18   ` Andrea Arcangeli

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=20170913131830.GA12833@redhat.com \
    --to=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.