[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61



 
> Date: Fri, 15 Apr 2011 14:22:29 -0700
> From: jeremy@xxxxxxxx
> To: tinnycloud@xxxxxxxxxxx
> CC: giamteckchoon@xxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx; konrad.wilk@xxxxxxxxxx
> Subject: Re: Kernel BUG at arch/x86/mm/tlb.c:61
>
> On 04/15/2011 05:23 AM, MaoXiaoyun wrote:
> > Hi:
> >
> > Could the crash related to this patch ?
> > http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commitdiff;h=45bfd7bfc6cf32f8e60bb91b32349f0b5090eea3
> >
> > Since now TLB state change to TLBSTATE_OK(mmu_context.h:40) is before
> > cpumask_clear_cpu(line 49).
> > Could it possible that right after execute line 40 of mmu_context.h,
> > CPU revice IPI from other CPU to
> > flush the mm, and when in interrupt, find the TLB state happened to be
> > TLBSTATE_OK. Which conflicts.
>
> Does reverting it help?
>
> J
 
Hi Jeremy:
 
    The lastest test result shows the reverting didn't help.
    Kernel panic exactly at the same place in tlb.c.
 
    I have question about TLB state, from the stack,
    xen_do_hypervisor_callback-> xen_evtchn_do_upcall->... ->drop_other_mm_ref
 
    What  cpu_tlbstate.state should be,  could  TLBSTATE_OK or TLBSTATE_LAZY all be possible?
    That is after a hypercall from userspace, state will be TLBSTATE_OK, and
      if from kernel space, state will be TLBSTATE_LAZE ?
 
       thanks.
   

 [<ffffffff8100e4a4>] drop_other_mm_ref+0x2a/0x53

 [<ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc

 [<ffffffff810100e8>] xen_call_function_single_interrupt+0x13/0x28

 [<ffffffff810a936a>] handle_IRQ_event+0x66/0x120

 [<ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e

 [<ffffffff8128c1a8>] __xen_evtchn_do_upcall+0x1ab/0x27d

 [<ffffffff8128dcf9>] xen_evtchn_do_upcall+0x33/0x46

 [<ffffffff81013efe>] xen_do_hypervisor_callback+0x1e/0x30


>
> >
> > Thanks.
> >
> > arch/x86/include/asm/mmu_context.h
> >
> > 33 static inline void switch_mm(struct mm_struct *prev, struct
> > mm_struct *next,
> > 34 <+++<+++<+++ struct task_struct *tsk)
> > 35 {
> > 36 <+++unsigned cpu = smp_processor_id();
> > 37
> > 38 <+++if (likely(prev != next)) {
> > 39 #ifdef CONFIG_SMP
> > 40 <+++<+++percpu_write(cpu_tlbstate.state, TLBSTATE_OK);
> > 41 <+++<+++percpu_write(cpu_tlbstate.active_mm, next);
> > 42 #endif
> > 43 <+++<+++cpumask_set_cpu(cpu, mm_cpumask(next));
> > 44
> > 45 <+++<+++/* Re-load page tables */
> > 46 <+++<+++load_cr3(next->pgd);
> > 47
> > 48 <+++<+++/* stop flush ipis for the previous mm */
> > 49 <+++<+++cpumask_clear_cpu(cpu, mm_cpumask(p rev));
> >
> >
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.