stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: wangnan0@huawei.com, aarcange@redhat.com,
	akpm@linux-foundation.org, guro@fb.com,
	khlebnikov@yandex-team.ru, liubo95@huawei.com,
	minchan@kernel.org, mingo@kernel.org, rientjes@google.com,
	stable@vger.kernel.org, torvalds@linux-foundation.org,
	will.deacon@arm.com, Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB entry
Date: Tue, 5 Dec 2017 18:10:59 +0100	[thread overview]
Message-ID: <20171205171059.GA23343@kroah.com> (raw)
In-Reply-To: <20171205093959.9537-1-mhocko@kernel.org>

On Tue, Dec 05, 2017 at 10:39:59AM +0100, Michal Hocko wrote:
> From: Wang Nan <wangnan0@huawei.com>
> 
> commit 687cb0884a714ff484d038e9190edc874edcf146 upstream.
> 
> tlb_gather_mmu(&tlb, mm, 0, -1) means gathering the whole virtual memory
> space.  In this case, tlb->fullmm is true.  Some archs like arm64
> doesn't flush TLB when tlb->fullmm is true:
> 
>   commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1").
> 
> Which causes leaking of tlb entries.
> 
> Will clarifies his patch:
>  "Basically, we tag each address space with an ASID (PCID on x86) which
>   is resident in the TLB. This means we can elide TLB invalidation when
>   pulling down a full mm because we won't ever assign that ASID to
>   another mm without doing TLB invalidation elsewhere (which actually
>   just nukes the whole TLB).
> 
>   I think that means that we could potentially not fault on a kernel
>   uaccess, because we could hit in the TLB"
> 
> There could be a window between complete_signal() sending IPI to other
> cores and all threads sharing this mm are really kicked off from cores.
> In this window, the oom reaper may calls tlb_flush_mmu_tlbonly() to
> flush TLB then frees pages.  However, due to the above problem, the TLB
> entries are not really flushed on arm64.  Other threads are possible to
> access these pages through TLB entries.  Moreover, a copy_to_user() can
> also write to these pages without generating page fault, causes
> use-after-free bugs.
> 
> This patch gathers each vma instead of gathering full vm space.  In this
> case tlb->fullmm is not true.  The behavior of oom reaper become similar
> to munmapping before do_exit, which should be safe for all archs.
> 
> Link: http://lkml.kernel.org/r/20171107095453.179940-1-wangnan0@huawei.com
> Fixes: aac453635549 ("mm, oom: introduce oom reaper")
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Acked-by: Michal Hocko <mhocko@suse.com>
> Acked-by: David Rientjes <rientjes@google.com>
> Cc: Minchan Kim <minchan@kernel.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Bob Liu <liubo95@huawei.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Roman Gushchin <guro@fb.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> [backported to 4.9 stable tree]
> Signed-off-by: Michal Hocko <mhocko@suse.com>

Thanks for the backport, now queued up.

greg k-h

      reply	other threads:[~2017-12-05 17:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-02  9:43 FAILED: patch "[PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB entry" failed to apply to 4.9-stable tree gregkh
2017-12-05  9:39 ` [PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB entry Michal Hocko
2017-12-05 17:10   ` Greg KH [this message]

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=20171205171059.GA23343@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=liubo95@huawei.com \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=mingo@kernel.org \
    --cc=rientjes@google.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=wangnan0@huawei.com \
    --cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).