Messages in this thread |  | | | Date | Sat, 5 Feb 2000 15:37:57 -0800 | | From | Richard Henderson <> | | Subject | Re: 2.3.42 alpha updates |
| |
On Sat, Feb 05, 2000 at 11:00:49PM +0100, Manfred Spraul wrote: > * Alpha doesn't use mm->cpu_vm_mask.
No, but there's no reason we couldn't.
> * the tlb could contain entries from multiple processes, > selected by the ASN.
Yes.
> * 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?
Yes, it's atomic. It's the reason we still have activate_mm, because we couldn't separate the two operations.
> 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!!
This doesn't happen because CPU1 did flush_tlb_other, either by noticing that mmA wasn't running on cpu1, or by noticing that mmA had more than one user.
But this leads to a different failing scenario:
CPU0: CPU1: switch_mm(A,mmA) this implies A->thread.asn and mmA->context are valid. flush_tlb_other(A) this implies mmA->context is 0. switch_to(A) Now A->thread.asn is out of sync with mmA->context.
This will require some thought to avoid scrogging schedule entirely.
r~
- 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/
|  |