Re: [BUG] kernel BUG at arch/x86/kernel/tlb_32.c:130!

[Ingo Molnar <mingo@elte.hu>]

* Li Zefan <lizf@cn.fujitsu.com> wrote:

> Ingo Molnar wrote:
> > * Ingo Molnar <mingo@elte.hu> wrote:
> > 
> >> * Li Zefan <lizf@cn.fujitsu.com> wrote:
> >>
> >>> I was using mmotm 2009-01-16-16-18, and I ran into this BUG,
> >>> the line is:
> >>> 	BUG_ON(cpumask_empty(cpumask));
> >>>
> >>> I suspect it is caused by:
> >>>
> >>> commit 4595f9620cda8a1e973588e743cf5f8436dd20c6
> >>> Author: Rusty Russell <rusty@rustcorp.com.au>
> >>> Date:   Sat Jan 10 21:58:09 2009 -0800
> >>>
> >>>     x86: change flush_tlb_others to take a const struct cpumask
> >>>
> >>>     Impact: reduce stack usage, use new cpumask API.
> >> Jaswinder reported a similar crash.
> >>
> >> Mike, Rusty, what's going on with this commit? Why does this code:
> >>
> >> +       if (cpumask_any_but(&mm->cpu_vm_mask, smp_processor_id()) < nr_cpu_ids)
> >> +               flush_tlb_others(&mm->cpu_vm_mask, mm, TLB_FLUSH_ALL);
> >>
> >> Assume that mm->cpu_vm_mask wont change? TLB flushes go async and the 
> >> MM's schedulability is not locked during that. I.e. mm->cpu_vm_mask can 
> >> change under you while the TLB flush IPIs are flying around - while when 
> >> the cpumask was passed on-stack this wouldnt happen.
> > 
> > okay, a testsystem of mine just triggered this crash too.
> > 
> > Li Zefan, Jaswinder, does the patch below fix it for you?
> > 
> 
> I'll test it, but I have to run for several hours to confirm it, since 
> the bug is not easy to trigger. :)

yes. It triggered on an old 32-bit dual-socket HyperThreading system for 
me and that is because HyperThreading is very good at triggering narrow 
SMP races. (which this one certainly is)

(I'd expect Nehalem to trigger this TLB flushing race more easily too, 
where HyperThreading made a comeback.)

	Ingo