On Wed, 2 Mar 2005, David S. Miller wrote: > Actually, I guess I could do the pte_cmpxchg() stuff, but only if it's > used to "add" access. If the TLB miss handler races, we just go into > the handle_mm_fault() path unnecessarily in order to synchronize. > > However, if this pte_cmpxchg() thing is used for removing access, then > sparc64 can't use it. In such a case a race in the TLB handler would > result in using an invalid PTE. I could "spin" on some lock bit, but > there is no way I'm adding instructions to the carefully constructed > TLB miss handler assembler on sparc64 just for that :-)
There is no need to provide pte_cmpxchg. If the arch does not support cmpxchg on ptes (CONFIG_ATOMIC_TABLE_OPS not defined) then it will fall back to using pte_get_and_clear while holding the page_table_lock to insure that the entry is not touched while performing the comparison. - 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/