Messages in this thread | | | Date | Thu, 18 Nov 2004 07:47:45 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [patch, 2.6.10-rc2] fix __flush_tlb*() preemption bug on CONFIG_PREEMPT |
| |
On Thu, 18 Nov 2004, Ingo Molnar wrote: > > note that reproducing this bug was only possible under PREEMPT_RT (there > it can be triggered in 30 seconds, with the right reproducer) - it needs > a really unlikely scenario which PREEMPT_RT's high concurrency does > offer but which is apparently much harder to reproduce in the vanilla > kernel. The patch fixes x86 and x64. Other architectures are most likely > safe, but they need review as well.
Ok, that's a pretty race.
However, I'm wondering whether this is the proper approach. After all, a lazy-tlb process should never have any reason to flush its TLB, since "its TLB" just aint there, and it ends up flushing somebody elses.
So I assume that this happens only with kswapd or similar? It really might be interesting to make the "we were a lazy tlb, and we're flushing somebody else" case do a stack dump, because I _suspect_ that this really is a special thing, and maybe the right thing to do is to make it special in _that_ path.
Very impressive debugging, btw. That must have been painful.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |