On Thu, Jul 13, 2017 at 9:05 AM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > 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? Yes. It could be a delta on top of Mel's patch. -- 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
