Re: What protects cpu_tlbstate?
Andi Kleen wrote: >> Hm, I was more wondering about simple compiler reordering. Does the >> relative order of setting and reading cpu_tlbstate.state, active_mm and >> the mm->cpu_vm_mask matter? >> > > Hmm, perhaps a barrier between state and active_mm might be a good idea. > Setting active_mm after state might be problematic. > cpu_vm_mask should be already a memory barrier. > Should leave_mm update active_mm and set the state to TLBSTATE_OK? Just reloading cr3 seems a bit blunt. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What protects cpu_tlbstate?
On Thursday 05 April 2007 23:00:22 Jeremy Fitzhardinge wrote: > Andi Kleen wrote: > > The interrupts can only happen when the other CPU is already lazy > > and enter_lazy_tlb would be a nop then. The flushers itself are > > synchronized by the page_table_lock or the mm semaphore. > > > > Against switch_mm it tries to protect with ordering. > > > > wmb()s are not needed on x86 (ok minus errata on ppro and > > VIA magic mode but which is UP only). That would leave some rmb()s, > > but I don't see any place they would be needed. > > > > Hm, I was more wondering about simple compiler reordering. Does the > relative order of setting and reading cpu_tlbstate.state, active_mm and > the mm->cpu_vm_mask matter? Hmm, perhaps a barrier between state and active_mm might be a good idea. Setting active_mm after state might be problematic. cpu_vm_mask should be already a memory barrier. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What protects cpu_tlbstate?
Andi Kleen wrote: > The interrupts can only happen when the other CPU is already lazy > and enter_lazy_tlb would be a nop then. The flushers itself are > synchronized by the page_table_lock or the mm semaphore. > > Against switch_mm it tries to protect with ordering. > > wmb()s are not needed on x86 (ok minus errata on ppro and > VIA magic mode but which is UP only). That would leave some rmb()s, > but I don't see any place they would be needed. > Hm, I was more wondering about simple compiler reordering. Does the relative order of setting and reading cpu_tlbstate.state, active_mm and the mm->cpu_vm_mask matter? J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What protects cpu_tlbstate?
On Thursday 05 April 2007 21:44:10 Jeremy Fitzhardinge wrote: > Hi, > > What protects the cpu_tlbstate? I see in i386/kernel/smp.c that its > always used in a non-preemptable area, but what prevents races with > interrupts? For example, what prevents leave_mm() called via the > flush_tlb_all IPI from racing with, say, enter_lazy_tlb? Couldn't a > race leave cpu_tlbstate in an inconsistent state? > > Or does it simply not matter? But if that were true, it seems to me > that there should be at least some barriers or something to make sure > the final state is consistent. The interrupts can only happen when the other CPU is already lazy and enter_lazy_tlb would be a nop then. The flushers itself are synchronized by the page_table_lock or the mm semaphore. Against switch_mm it tries to protect with ordering. wmb()s are not needed on x86 (ok minus errata on ppro and VIA magic mode but which is UP only). That would leave some rmb()s, but I don't see any place they would be needed. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What protects cpu_tlbstate?
On Thursday 05 April 2007 21:44:10 Jeremy Fitzhardinge wrote: Hi, What protects the cpu_tlbstate? I see in i386/kernel/smp.c that its always used in a non-preemptable area, but what prevents races with interrupts? For example, what prevents leave_mm() called via the flush_tlb_all IPI from racing with, say, enter_lazy_tlb? Couldn't a race leave cpu_tlbstate in an inconsistent state? Or does it simply not matter? But if that were true, it seems to me that there should be at least some barriers or something to make sure the final state is consistent. The interrupts can only happen when the other CPU is already lazy and enter_lazy_tlb would be a nop then. The flushers itself are synchronized by the page_table_lock or the mm semaphore. Against switch_mm it tries to protect with ordering. wmb()s are not needed on x86 (ok minus errata on ppro and VIA magic mode but which is UP only). That would leave some rmb()s, but I don't see any place they would be needed. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What protects cpu_tlbstate?
Andi Kleen wrote: The interrupts can only happen when the other CPU is already lazy and enter_lazy_tlb would be a nop then. The flushers itself are synchronized by the page_table_lock or the mm semaphore. Against switch_mm it tries to protect with ordering. wmb()s are not needed on x86 (ok minus errata on ppro and VIA magic mode but which is UP only). That would leave some rmb()s, but I don't see any place they would be needed. Hm, I was more wondering about simple compiler reordering. Does the relative order of setting and reading cpu_tlbstate.state, active_mm and the mm-cpu_vm_mask matter? J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What protects cpu_tlbstate?
On Thursday 05 April 2007 23:00:22 Jeremy Fitzhardinge wrote: Andi Kleen wrote: The interrupts can only happen when the other CPU is already lazy and enter_lazy_tlb would be a nop then. The flushers itself are synchronized by the page_table_lock or the mm semaphore. Against switch_mm it tries to protect with ordering. wmb()s are not needed on x86 (ok minus errata on ppro and VIA magic mode but which is UP only). That would leave some rmb()s, but I don't see any place they would be needed. Hm, I was more wondering about simple compiler reordering. Does the relative order of setting and reading cpu_tlbstate.state, active_mm and the mm-cpu_vm_mask matter? Hmm, perhaps a barrier between state and active_mm might be a good idea. Setting active_mm after state might be problematic. cpu_vm_mask should be already a memory barrier. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What protects cpu_tlbstate?
Andi Kleen wrote: Hm, I was more wondering about simple compiler reordering. Does the relative order of setting and reading cpu_tlbstate.state, active_mm and the mm-cpu_vm_mask matter? Hmm, perhaps a barrier between state and active_mm might be a good idea. Setting active_mm after state might be problematic. cpu_vm_mask should be already a memory barrier. Should leave_mm update active_mm and set the state to TLBSTATE_OK? Just reloading cr3 seems a bit blunt. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
