On Thu, 13 Sep 2018 11:21:11 +0200 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > Write a comment explaining some of this.. > > Cc: Will Deacon <will.deacon@xxxxxxx> > Cc: "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: Nick Piggin <npiggin@xxxxxxxxx> > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx> > --- > include/asm-generic/tlb.h | 120 ++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 117 insertions(+), 3 deletions(-) > > --- a/include/asm-generic/tlb.h > +++ b/include/asm-generic/tlb.h > @@ -22,6 +22,119 @@ > > #ifdef CONFIG_MMU > > +/* > + * Generic MMU-gather implementation. > + * > + * The mmu_gather data structure is used by the mm code to implement the > + * correct and efficient ordering of freeing pages and TLB invalidations. > + * > + * This correct ordering is: > + * > + * 1) unhook page > + * 2) TLB invalidate page > + * 3) free page > + * > + * That is, we must never free a page before we have ensured there are no live > + * translations left to it. Otherwise it might be possible to observe (or > + * worse, change) the page content after it has been reused. > + * This first comment already includes the reason why s390 is probably better off with its own mmu-gather implementation. It depends on the situation if we have 1) unhook the page and do a TLB flush at the same time 2) free page or 1) unhook page 2) free page 3) final TLB flush of the whole mm A variant of the second order we had in the past is to do the mm TLB flush first, then the unhooks and frees of the individual pages. The are some tricky corners switching between the two variants, see finish_arch_post_lock_switch. The point is: we *never* have the order 1) unhook, 2) TLB invalidate, 3) free. If there is concurrency due to a multi-threaded application we have to do the unhook of the page-table entry and the TLB flush with a single instruction. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
