Andy Lutomirski <luto@xxxxxxxxxx> wrote: > 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. Yes, you are right. This approach requires a counter that is only updated after the flush is completed by all cores. This way you ensure there is no CPU that did not complete the flush. Does it make sense? -- 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
