Andi Kleen wrote:
>> ; it does
>> seem perfectly acceptable though for the mm code to use kmap or vmap
>> (not kmap_atomic) internally somewhere in the pagetable code.
>>
>
> i386 does it all the time for highmem pagetables in fact.
>
Yes, it uses kmap_atomic(_pte) all the time. Is that
Andi Kleen wrote:
>> I agree. The patch is a nop. I just got overly paranoid. The whole
>> thing is just very prone to bugs.
>>
> So do we need a patch for .23 or not?
>
Forgot this bit. No, I think the upshot is that it isn't necessary (nor
Rusty's).
J
-
To unsubscribe from this
Andi Kleen wrote:
; it does
seem perfectly acceptable though for the mm code to use kmap or vmap
(not kmap_atomic) internally somewhere in the pagetable code.
i386 does it all the time for highmem pagetables in fact.
Yes, it uses kmap_atomic(_pte) all the time. Is that what you
Andi Kleen wrote:
I agree. The patch is a nop. I just got overly paranoid. The whole
thing is just very prone to bugs.
So do we need a patch for .23 or not?
Forgot this bit. No, I think the upshot is that it isn't necessary (nor
Rusty's).
J
-
To unsubscribe from this list:
>I agree. The patch is a nop. I just got overly paranoid. The whole
>thing is just very prone to bugs.
So do we need a patch for .23 or not?
>; it does
> seem perfectly acceptable though for the mm code to use kmap or vmap
> (not kmap_atomic) internally somewhere in the pagetable code.
i386
On Thu, 2007-09-06 at 06:37 +1000, Rusty Russell wrote:
> On Thu, 2007-08-23 at 22:46 -0700, Zachary Amsden wrote:
> > I recently sent off a fix for lazy vmalloc faults which can happen under
> > paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
> > bit on fixing this. I
On Thu, 2007-08-23 at 22:46 -0700, Zachary Amsden wrote:
> I recently sent off a fix for lazy vmalloc faults which can happen under
> paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
> bit on fixing this. I neglected to notice that since the new call to
> flush the MMU
Rusty Russell wrote:
> On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
>
>> Rusty Russell wrote:
>>
>>> static inline void arch_flush_lazy_mmu_mode(void)
>>> {
>>> - PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
>>> + if (unlikely(__get_cpu_var(paravirt_lazy_mode) ==
On Wed, 2007-09-05 at 10:05 -0700, Zachary Amsden wrote:
> On Thu, 2007-09-06 at 02:33 +1000, Rusty Russell wrote:
> > + BUG_ON(get_lazy_mode() && !(mode == PARAVIRT_LAZY_NONE |
> > + | mode == PARAVIRT_LAZY_FLUSH));
>
> That's a pretty strange line break.
Sorry,
On Thu, 2007-09-06 at 02:33 +1000, Rusty Russell wrote:
> On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
> > Rusty Russell wrote:
> > > static inline void arch_flush_lazy_mmu_mode(void)
> > > {
> > > - PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
> > > + if
On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > static inline void arch_flush_lazy_mmu_mode(void)
> > {
> > - PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
> > + if (unlikely(__get_cpu_var(paravirt_lazy_mode) == PARAVIRT_LAZY_MMU))
> > +
On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
Rusty Russell wrote:
static inline void arch_flush_lazy_mmu_mode(void)
{
- PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
+ if (unlikely(__get_cpu_var(paravirt_lazy_mode) == PARAVIRT_LAZY_MMU))
+
On Thu, 2007-09-06 at 02:33 +1000, Rusty Russell wrote:
On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
Rusty Russell wrote:
static inline void arch_flush_lazy_mmu_mode(void)
{
- PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
+ if
Rusty Russell wrote:
On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
Rusty Russell wrote:
static inline void arch_flush_lazy_mmu_mode(void)
{
- PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
+ if (unlikely(__get_cpu_var(paravirt_lazy_mode) ==
On Thu, 2007-08-23 at 22:46 -0700, Zachary Amsden wrote:
I recently sent off a fix for lazy vmalloc faults which can happen under
paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
bit on fixing this. I neglected to notice that since the new call to
flush the MMU update
On Thu, 2007-09-06 at 06:37 +1000, Rusty Russell wrote:
On Thu, 2007-08-23 at 22:46 -0700, Zachary Amsden wrote:
I recently sent off a fix for lazy vmalloc faults which can happen under
paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
bit on fixing this. I neglected
Rusty Russell wrote:
> static inline void arch_flush_lazy_mmu_mode(void)
> {
> - PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
> + if (unlikely(__get_cpu_var(paravirt_lazy_mode) == PARAVIRT_LAZY_MMU))
> + arch_leave_lazy_mmu_mode();
> }
>
This changes the semantics a
Rusty Russell wrote:
static inline void arch_flush_lazy_mmu_mode(void)
{
- PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
+ if (unlikely(__get_cpu_var(paravirt_lazy_mode) == PARAVIRT_LAZY_MMU))
+ arch_leave_lazy_mmu_mode();
}
This changes the semantics a bit;
On Sat, 2007-09-01 at 14:09 -0700, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > Do you agree it is better to be safe than sorry in this case? The
> > kind of bugs introduced by getting this wrong are really hard to find,
> > and I would rather err on the side of an extra increment and
On Sat, 2007-09-01 at 14:09 -0700, Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Do you agree it is better to be safe than sorry in this case? The
kind of bugs introduced by getting this wrong are really hard to find,
and I would rather err on the side of an extra increment and
Zachary Amsden wrote:
> Do you agree it is better to be safe than sorry in this case? The
> kind of bugs introduced by getting this wrong are really hard to find,
> and I would rather err on the side of an extra increment and decrement
> of preempt_count that causing a regression.
I think this
Zachary Amsden wrote:
Do you agree it is better to be safe than sorry in this case? The
kind of bugs introduced by getting this wrong are really hard to find,
and I would rather err on the side of an extra increment and decrement
of preempt_count that causing a regression.
I think this patch
On Thu, 2007-08-23 at 23:59 -0700, Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
> > Hm. Doing any kind of lazy-state operation with preemption enabled is
> > fundamentally meaningless. How does it get into a preemptable state
> >
>
> Agree 100%. It is the lazy mode flush that might
On Thu, 2007-08-23 at 23:59 -0700, Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Hm. Doing any kind of lazy-state operation with preemption enabled is
fundamentally meaningless. How does it get into a preemptable state
Agree 100%. It is the lazy mode flush that might happen when
Jeremy Fitzhardinge wrote:
Hm. Doing any kind of lazy-state operation with preemption enabled is
fundamentally meaningless. How does it get into a preemptable state
Agree 100%. It is the lazy mode flush that might happen when preempt is
enabled, but lazy mode is disabled. In that case,
Zachary Amsden wrote:
> I recently sent off a fix for lazy vmalloc faults which can happen
> under paravirt when lazy mode is enabled. Unfortunately, I jumped the
> gun a bit on fixing this. I neglected to notice that since the new
> call to flush the MMU update queue is called from the page
Zachary Amsden wrote:
I recently sent off a fix for lazy vmalloc faults which can happen
under paravirt when lazy mode is enabled. Unfortunately, I jumped the
gun a bit on fixing this. I neglected to notice that since the new
call to flush the MMU update queue is called from the page fault
Jeremy Fitzhardinge wrote:
Hm. Doing any kind of lazy-state operation with preemption enabled is
fundamentally meaningless. How does it get into a preemptable state
Agree 100%. It is the lazy mode flush that might happen when preempt is
enabled, but lazy mode is disabled. In that case,
I recently sent off a fix for lazy vmalloc faults which can happen under
paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
bit on fixing this. I neglected to notice that since the new call to
flush the MMU update queue is called from the page fault handler, it can
be
I recently sent off a fix for lazy vmalloc faults which can happen under
paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
bit on fixing this. I neglected to notice that since the new call to
flush the MMU update queue is called from the page fault handler, it can
be
30 matches
Mail list logo
