Andi Kleen wrote:
I think I would prefer you touch the generic code. This new hook is ugly.
What new hook? The hook has been there for sometime, and now we are
using it to fix a bug. I do not want to touch generic or arch code at
this point in the 2.6.21 release.
And the lazy mode is
On Saturday 31 March 2007 10:45, Zachary Amsden wrote:
> So lazy MMU mode is vulnerable to interrupts coming in and issuing
> kmap_atomic, which does not work when under lazy MMU mode. The window
> for this is small, but it means highmem kernels, especially with heavy
> network, USB, or AIO
Jeremy Fitzhardinge wrote:
The comment only talks about disabling interrupts for lazy_mmu, but this
seems to do it for lazy_cpu as well. Is that OK? What happens if
someone wants to change interrupt states under lazy_cpu; I can't think
of an inherent reason why that wouldn't be allowed
Andrew Morton wrote:
> On Sat, 31 Mar 2007 00:45:59 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
>
>
>> +static void vmi_set_lazy_mode(int new_mode)
>> +{
>> +static DEFINE_PER_CPU(int, mode);
>> +static DEFINE_PER_CPU(unsigned long, flags);
>> +int cpu = smp_processor_id();
>>
Zachary Amsden wrote:
> Critical bugfix; when using software RAID, potentially USB or AIO in
> highmem configurations, drivers are allowed to use kmap_atomic from
> interrupt context. This is incompatible with the current implementation
> of lazy MMU mode, and means the kmap will silently fail,
On Sat, 31 Mar 2007 00:45:59 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
> +static void vmi_set_lazy_mode(int new_mode)
> +{
> + static DEFINE_PER_CPU(int, mode);
> + static DEFINE_PER_CPU(unsigned long, flags);
> + int cpu = smp_processor_id();
That will cause upset if
So lazy MMU mode is vulnerable to interrupts coming in and issuing
kmap_atomic, which does not work when under lazy MMU mode. The window
for this is small, but it means highmem kernels, especially with heavy
network, USB, or AIO workloads are vulnerable to getting invariably
fatal pagefaults
So lazy MMU mode is vulnerable to interrupts coming in and issuing
kmap_atomic, which does not work when under lazy MMU mode. The window
for this is small, but it means highmem kernels, especially with heavy
network, USB, or AIO workloads are vulnerable to getting invariably
fatal pagefaults
On Sat, 31 Mar 2007 00:45:59 -0800 Zachary Amsden [EMAIL PROTECTED] wrote:
+static void vmi_set_lazy_mode(int new_mode)
+{
+ static DEFINE_PER_CPU(int, mode);
+ static DEFINE_PER_CPU(unsigned long, flags);
+ int cpu = smp_processor_id();
That will cause upset if
Zachary Amsden wrote:
Critical bugfix; when using software RAID, potentially USB or AIO in
highmem configurations, drivers are allowed to use kmap_atomic from
interrupt context. This is incompatible with the current implementation
of lazy MMU mode, and means the kmap will silently fail,
Andrew Morton wrote:
On Sat, 31 Mar 2007 00:45:59 -0800 Zachary Amsden [EMAIL PROTECTED] wrote:
+static void vmi_set_lazy_mode(int new_mode)
+{
+static DEFINE_PER_CPU(int, mode);
+static DEFINE_PER_CPU(unsigned long, flags);
+int cpu = smp_processor_id();
That will
Jeremy Fitzhardinge wrote:
The comment only talks about disabling interrupts for lazy_mmu, but this
seems to do it for lazy_cpu as well. Is that OK? What happens if
someone wants to change interrupt states under lazy_cpu; I can't think
of an inherent reason why that wouldn't be allowed
On Saturday 31 March 2007 10:45, Zachary Amsden wrote:
So lazy MMU mode is vulnerable to interrupts coming in and issuing
kmap_atomic, which does not work when under lazy MMU mode. The window
for this is small, but it means highmem kernels, especially with heavy
network, USB, or AIO
Andi Kleen wrote:
I think I would prefer you touch the generic code. This new hook is ugly.
What new hook? The hook has been there for sometime, and now we are
using it to fix a bug. I do not want to touch generic or arch code at
this point in the 2.6.21 release.
And the lazy mode is
14 matches
Mail list logo
