|   xen-devel
[Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61 
| To: | <jeremy@xxxxxxxx> |  
| Subject: | [Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61 |  
| From: | MaoXiaoyun <tinnycloud@xxxxxxxxxxx> |  
| Date: | Mon, 25 Apr 2011 12:42:48 +0800 |  
| Cc: | xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, giamteckchoon@xxxxxxxxx,	konrad.wilk@xxxxxxxxxx |  
| Delivery-date: | Sun, 24 Apr 2011 21:43:37 -0700 |  
| Envelope-to: | www-data@xxxxxxxxxxxxxxxxxxx |  
| Importance: | Normal |  
| In-reply-to: | <4DA8B715.9080508@xxxxxxxx> |  
| List-help: | <mailto:xen-devel-request@lists.xensource.com?subject=help> |  
| List-id: | Xen developer discussion <xen-devel.lists.xensource.com> |  
| List-post: | <mailto:xen-devel@lists.xensource.com> |  
| List-subscribe: | <http://lists.xensource.com/mailman/listinfo/xen-devel>,	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |  
| List-unsubscribe: | <http://lists.xensource.com/mailman/listinfo/xen-devel>,	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |  
| References: | <COL0-MC1-F14hmBzxHs00230882@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,	<BLU157-w488E5FEBD5E2DBC0666EF1DAA70@xxxxxxx>,	<BLU157-w5025BFBB4B1CDFA7AA0966DAA90@xxxxxxx>,	<BLU157-w540B39FBA137B4D96278D2DAA90@xxxxxxx>,	<BANLkTimgh_iip27zkDPNV9r7miwbxHmdVg@xxxxxxxxxxxxxx>,	<BANLkTimkMgYNyANcKiZu5tJTL4==zdP3xg@xxxxxxxxxxxxxx>,	<BLU157-w116F1BB57ABFDE535C7851DAA80@xxxxxxx>,	<4DA3438A.6070503@xxxxxxxx>,	<BLU157-w2C6CD57CEA345B8D115E8DAAB0@xxxxxxx>,	<BLU157-w36F4E0A7503A357C9DE6A3DAAB0@xxxxxxx>,	<20110412100000.GA15647@xxxxxxxxxxxx>,	<BLU157-w14B84A51C80B41AB72B6CBDAAD0@xxxxxxx>,	<BANLkTinNxLnJxtZD68ODLSJqafq0tDRPfw@xxxxxxxxxxxxxx>,	<BLU157-w30A1A208238A9031F0D18EDAAD0@xxxxxxx>,	<BLU157-w383D1A2536480BCD4C0E0EDAAD0@xxxxxxx>	<BLU157-w42DAD248C94153635E9749DAAC0@xxxxxxx>,	<4DA8B715.9080508@xxxxxxxx> |  
| Sender: | xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |  
| | I go through the switch_mm more, and come up one more question: 
 Why we don't need to clear prev cpumask in line between line 59 and 60?
 
 Say
 1)  Context is switch from process A to kernel, then kernel has active_mm-> A's mm
 2)  Context is switch from kernel to A, in sched.c oldmm = A's mm; mm = A's mm
 3)  it will call arch/x86/include/asm/mmu_context.h:60, since prev = next;
 if another CPU flush A's mm, but this cpu don't clear CPU mask, it might enter IPI interrput
 routine, and also find cpu_tlbstate.state is TLBSTATE_OK.
 
 Could this possible?
 
 kernel/sched.c
 
 2999 context_switch(struct rq *rq, struct task_struct *prev,
 3000            struct task_struct *next)
 3001 {
 3002     struct mm_struct *mm, *oldmm;
 3003
 3004     prepare_task_switch(rq, prev, next);
 3005     trace_sched_switch(rq, prev, next);
 3006     mm = next->mm;
 3007     oldmm = prev->active_mm;
 3008     /*
 3009      * For paravirt, this is coupled with an exit in switch_to to
 3010      * combine the page table reload and the switch backend into
 3011      * one hypercall.
 3012      */
 3013     arch_start_context_switch(prev);
 3014
 3015     if (unlikely(!mm)) {
 3016         next->active_mm = oldmm;
 3017         atomic_inc(&oldmm->mm_count);
 3018         enter_lazy_tlb(oldmm, next);
 3019     } else
 3020         switch_mm(oldmm, mm, next);
 3021
 3022     if (unlikely(!prev->mm)) {
 3023         prev->active_mm = NULL;
 3024         rq->prev_mm = oldmm;
 3025     }
 
 
 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         /* stop flush ipis for the previous mm */
 40         cpumask_clear_cpu(cpu, mm_cpumask(prev));
 41
 42
 43 #ifdef CONFIG_SMP
 44         percpu_write(cpu_tlbstate.state, TLBSTATE_OK);
 45         percpu_write(cpu_tlbstate.active_mm, next);
 46 #endif
 47         cpumask_set_cpu(cpu, mm_cpumask(next));
 48 <
 BR> 49         /* Re-load page tables */
 50         load_cr3(next->pgd);
 51
 52         /*
 53          * load the LDT, if the LDT is different:
 54          */
 55         if (unlikely(prev->context.ldt != next->context.ldt))
 56             load_LDT_nolock(&next->context);
 57     }
 58 #ifdef CONFIG_SMP
 59     else {
 60         percpu_write(cpu_tlbstate.state, TLBSTATE_OK);
 61         BUG_ON(percpu_read(cpu_tlbstate.active_mm) != 
 next);
 62
 63         if (!cpumask_test_and_set_cpu(cpu, mm_cpumask(next))) {
 64             /* We were in lazy tlb mode and leave_mm disabled
 65              * tlb flush IPI delivery. We must reload CR3
 66              * to make sure to use no freed page tables.
 67              */
 68             load_cr3(next->pgd);
 69             load_LDT_nolock(&next->context);
 70         }
 71     }
 
 | 
 _______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 | 
 
| <Prev in Thread] | Current Thread | [Next in Thread> |  | 
[Xen-devel] Re: kernel BUG at arch/x86/xen/mmu.c:1860!, Joerg Stephan[Xen-devel] Re: Kernel BUG at arch/x86/mm/tlb.c:61, (continued)
Re: [Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61, Jeremy Fitzhardinge
RE: [Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61, Tian, Kevin
RE: [Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61, MaoXiaoyun
RE: [Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61, Tian, Kevin
[Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61,
MaoXiaoyun <=
[Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61, MaoXiaoyun
[Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61, MaoXiaoyun
[Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61, MaoXiaoyun
RE: [Xen-devel] RE: Kernel BUG at arch/x86/mm/tlb.c:61, Tian, Kevin
[Xen-devel] Re: kernel BUG at arch/x86/xen/mmu.c:1872, Teck Choon Giam
 |  |  |