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 c
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 wor
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 (though
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, ca
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 CONFIG_PRE
6 matches
Mail list logo
