From: Samu Kallio
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:
-
From: Samu Kallio samu.kal...@aberdeencloud.com
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
On Thu, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
> On 02/28/2013 11:22 AM, Borislav Petkov wrote:
> >On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
> >>On 02/28/2013 11:10 AM, Borislav Petkov wrote:
> >>>On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin
On Thu, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
> What was the suggestion exactly? I don't remember seeing that message.
Use the paravirt patching facility to replace arch_flush_lazy_mmu_mode()
with a nop when running on baremetal. I.e., the whole functionality
around
On 02/28/2013 11:22 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
On 02/28/2013 08:22 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
>> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
>>> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
> >On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> >>At the very least we should have an early filter for the **COMMON!**
> >>case that we are not on a PV platform.
>
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
case that we are not on a PV platform.
... or, patch it out with the alternatives on baremetal, as Steven
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> At the very least we should have an early filter for the **COMMON!**
> case that we are not on a PV platform.
... or, patch it out with the alternatives on baremetal, as Steven
suggested.
--
Regards/Gruss,
Boris.
Sent from a
On 02/28/2013 07:38 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>> index fb674fd..4f7d793 100644
>> --- a/arch/x86/mm/fault.c
>> +++ b/arch/x86/mm/fault.c
>> @@ -378,10 +378,12 @@
On Thu, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index fb674fd..4f7d793 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned
>
8367d5 Mon Sep 17 00:00:00 2001
From: Samu Kallio
Date: Sun, 17 Feb 2013 02:35:52 +0000
Subject: [PATCH] x86: mm: Fix vmalloc_fault oops during lazy MMU updates.
In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are be
: Sun, 17 Feb 2013 02:35:52 +
Subject: [PATCH] x86: mm: Fix vmalloc_fault oops during lazy MMU updates.
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
On Thu, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fb674fd..4f7d793 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
On 02/28/2013 07:38 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fb674fd..4f7d793 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -378,10 +378,12 @@ static noinline
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
case that we are not on a PV platform.
... or, patch it out with the alternatives on baremetal, as Steven
suggested.
--
Regards/Gruss,
Boris.
Sent from a
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
case that we are not on a PV platform.
... or, patch it out with the alternatives on baremetal, as Steven
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
case that we are not on a PV platform.
... or,
On 02/28/2013 08:22 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
On 02/28/2013 11:22 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
On Thu, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
What was the suggestion exactly? I don't remember seeing that message.
Use the paravirt patching facility to replace arch_flush_lazy_mmu_mode()
with a nop when running on baremetal. I.e., the whole functionality
around
On Thu, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
On 02/28/2013 11:22 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At
On Thu, Feb 21, 2013 at 05:56:35PM +0200, Samu Kallio wrote:
> On Thu, Feb 21, 2013 at 2:33 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Sun, Feb 17, 2013 at 02:35:52AM -, Samu Kallio wrote:
> >> In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
> >> when lazy MMU updates are
On Thu, Feb 21, 2013 at 05:56:35PM +0200, Samu Kallio wrote:
On Thu, Feb 21, 2013 at 2:33 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Sun, Feb 17, 2013 at 02:35:52AM -, Samu Kallio wrote:
In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU
On Thu, Feb 21, 2013 at 2:33 PM, Konrad Rzeszutek Wilk
wrote:
> On Sun, Feb 17, 2013 at 02:35:52AM -, 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
On Sun, Feb 17, 2013 at 02:35:52AM -, 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
On Sun, Feb 17, 2013 at 02:35:52AM -, 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
On Thu, Feb 21, 2013 at 2:33 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Sun, Feb 17, 2013 at 02:35:52AM -, 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.
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
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
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
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
32 matches
Mail list logo
