On Wed, Jul 12, 2017 at 4:42 PM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > Andy Lutomirski <luto@xxxxxxxxxx> wrote: > >> On Wed, Jul 12, 2017 at 4:27 PM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote: >>> Actually, I think that based on Andy’s patches there is a relatively >>> reasonable solution. For each mm we will hold both a “pending_tlb_gen” >>> (increased under the PT-lock) and an “executed_tlb_gen”. Once >>> flush_tlb_mm_range finishes flushing it will use cmpxchg to update the >>> executed_tlb_gen to the pending_tlb_gen that was prior the flush (the >>> cmpxchg will ensure the TLB gen only goes forward). Then, whenever >>> pending_tlb_gen is different than executed_tlb_gen - a flush is needed. >> >> Why do we need executed_tlb_gen? We already have >> cpu_tlbstate.ctxs[...].tlb_gen. Or is the idea that executed_tlb_gen >> guarantees that all cpus in mm_cpumask are at least up to date to >> executed_tlb_gen? > > Hm... So actually it may be enough, no? Just compare mm->context.tlb_gen > with cpu_tlbstate.ctxs[...].tlb_gen and flush if they are different? > Wouldn't that still leave the races where the CPU observing the stale TLB entry isn't the CPU that did munmap/mprotect/whatever? I think executed_tlb_gen or similar may really be needed for your approach. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
