From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Samu Kallio <samu.kallio@aberdeencloud.com>,
mingo@redhat.com, Jeremy Fitzhardinge <jeremy@goop.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: x86: mm: Fix vmalloc_fault oops during lazy MMU updates.
Date: Thu, 21 Feb 2013 07:33:06 -0500 [thread overview]
Message-ID: <20130221123306.GA6781@phenom.dumpdata.com> (raw)
In-Reply-To: <1361068552-21529-1-git-send-email-samu.kallio@aberdeencloud.com>
On Sun, Feb 17, 2013 at 02:35:52AM -0000, Samu Kallio wrote:
> In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
> when lazy MMU updates are enabled, because set_pgd effects are being
> deferred.
>
> One instance of this problem is during process mm cleanup with memory
> cgroups enabled. The chain of events is as follows:
>
> - zap_pte_range enables lazy MMU updates
> - zap_pte_range eventually calls mem_cgroup_charge_statistics,
> which accesses the vmalloc'd mem_cgroup per-cpu stat area
> - vmalloc_fault is triggered which tries to sync the corresponding
> PGD entry with set_pgd, but the update is deferred
> - vmalloc_fault oopses due to a mismatch in the PUD entries
>
> Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
> changes visible to the consistency checks.
How do you reproduce this? Is there a BUG() or WARN() trace that
is triggered when this happens?
Also pls next time also CC me.
>
> Signed-off-by: Samu Kallio <samu.kallio@aberdeencloud.com>
>
> ---
> arch/x86/mm/fault.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 8e13ecb..0a45298 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned long address)
> if (pgd_none(*pgd_ref))
> return -1;
>
> - if (pgd_none(*pgd))
> + if (pgd_none(*pgd)) {
> set_pgd(pgd, *pgd_ref);
> - else
> + arch_flush_lazy_mmu_mode();
> + } else {
> BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
> + }
>
> /*
> * Below here mismatches are bugs because these lower tables
next prev parent reply other threads:[~2013-02-21 12:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-17 2:35 [PATCH] x86: mm: Fix vmalloc_fault oops during lazy MMU updates Samu Kallio
2013-02-21 12:33 ` Konrad Rzeszutek Wilk [this message]
2013-02-21 15:56 ` Samu Kallio
2013-02-23 1:06 ` Konrad Rzeszutek Wilk
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=20130221123306.GA6781@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=samu.kallio@aberdeencloud.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.