Richard Henderson wrote:
>
> On Sat, Feb 05, 2000 at 11:57:34AM +0100, Manfred Spraul wrote:
> > It seems that Alpha is broken, because it relies on "current->active_mm"
> > to check if a flush is required.
>
> Indeed it is broken. What do you think of the following?
>
> r~
Hmm. I don't understand the current alpha code, so it's a bit difficult
do verify your new code ;)
It seems that
* Alpha doesn't use mm->cpu_vm_mask.
* the tlb could contain entries from multiple processes, selected by the
ASN.
* the actual page table pointer is changed during switch_to(), not
during switch_mm(). Is that an atomic operation, or could IPI's arrive
between the page table pointer/ASN change and the "current" change?
If the change is atomic, then "current->active_mm" and the page table
pointer are always in sync, so the i386 problem doesn't exist on Alpha.
But I don't understand what happens in the following scenario:
CPU0: CPU1:
thread mmA page stealer(kswapd)
thread switch to mmB
changes a page from mmA
flush_tlb_page(mmA,...)
IPI!
* notices that mmA is not loaded, no flush
* mmA stored in .delayed_flush
thread switch back to mmA
* prepare_to_switch() clears .delayed_flush
switch_mm(): ASN not yet wrapped, tlb reactivated.
!! data access without tlb flush!!
Weird.
I assumed that mm->cpu_vm_mask is intended for cpu's with ASN's: it
should be a bit field, if the n'th bit is set, then the tlb of the n'th
cpu could contain entries from that mm.
flush IPI's are sent to all cpu's in that bitfield, the problem is how
to update that bitfield because you may not rely on "current->active_mm"
from within the IPI handler.
-- Manfred- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:12 EST