LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Minchan Kim <firstname.lastname@example.org> To: Michal Hocko <email@example.com> Cc: Wang Nan <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, Bob Liu <firstname.lastname@example.org>, Andrew Morton <email@example.com>, David Rientjes <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Roman Gushchin <firstname.lastname@example.org>, Konstantin Khlebnikov <email@example.com>, Andrea Arcangeli <firstname.lastname@example.org> Subject: Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy (was: Re: [RESEND PATCH] mm, oom_reaper: gather each vma to prevent) leaking TLB entry Date: Mon, 13 Nov 2017 09:28:33 +0900 [thread overview] Message-ID: <20171113002833.GA18301@bbox> (raw) In-Reply-To: <email@example.com> On Fri, Nov 10, 2017 at 01:26:35PM +0100, Michal Hocko wrote: > On Fri 10-11-17 11:15:29, Michal Hocko wrote: > > On Fri 10-11-17 09:19:33, Minchan Kim wrote: > > > On Tue, Nov 07, 2017 at 09:54:53AM +0000, Wang Nan wrote: > > > > tlb_gather_mmu(&tlb, mm, 0, -1) means gathering the whole virtual memory > > > > space. In this case, tlb->fullmm is true. Some archs like arm64 doesn't > > > > flush TLB when tlb->fullmm is true: > > > > > > > > commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1"). > > > > > > > > Which makes leaking of tlb entries. > > > > > > That means soft-dirty which has used tlb_gather_mmu with fullmm could be > > > broken via losing write-protection bit once it supports arm64 in future? > > > > > > If so, it would be better to use TASK_SIZE rather than -1 in tlb_gather_mmu. > > > Of course, it's a off-topic. > > > > I wouldn't play tricks like that. And maybe the API itself could be more > > explicit. E.g. add a lazy parameter which would allow arch specific code > > to not flush if it is sure that nobody can actually stumble over missed > > flush. E.g. the following? > > This one has a changelog and even compiles on my crosscompile test > --- > From 7f0fcd2cab379ddac5611b2a520cdca8a77a235b Mon Sep 17 00:00:00 2001 > From: Michal Hocko <firstname.lastname@example.org> > Date: Fri, 10 Nov 2017 11:27:17 +0100 > Subject: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy > > 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1") has > introduced an optimization to not flush tlb when we are tearing the > whole address space down. Will goes on to explain > > : Basically, we tag each address space with an ASID (PCID on x86) which > : is resident in the TLB. This means we can elide TLB invalidation when > : pulling down a full mm because we won't ever assign that ASID to > : another mm without doing TLB invalidation elsewhere (which actually > : just nukes the whole TLB). > > This all is nice but tlb_gather users are not aware of that and this can > actually cause some real problems. E.g. the oom_reaper tries to reap the > whole address space but it might race with threads accessing the memory . > It is possible that soft-dirty handling might suffer from the same > problem . > > Introduce an explicit lazy variant tlb_gather_mmu_lazy which allows the > behavior arm64 implements for the fullmm case and replace it by an > explicit lazy flag in the mmu_gather structure. exit_mmap path is then > turned into the explicit lazy variant. Other architectures simply ignore > the flag. > >  http://email@example.com >  http://lkml.kernel.org/r/20171110001933.GA12421@bbox > Signed-off-by: Michal Hocko <firstname.lastname@example.org> > --- > arch/arm/include/asm/tlb.h | 3 ++- > arch/arm64/include/asm/tlb.h | 2 +- > arch/ia64/include/asm/tlb.h | 3 ++- > arch/s390/include/asm/tlb.h | 3 ++- > arch/sh/include/asm/tlb.h | 2 +- > arch/um/include/asm/tlb.h | 2 +- > include/asm-generic/tlb.h | 6 ++++-- > include/linux/mm_types.h | 2 ++ > mm/memory.c | 17 +++++++++++++++-- > mm/mmap.c | 2 +- > 10 files changed, 31 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h > index d5562f9ce600..fe9042aee8e9 100644 > --- a/arch/arm/include/asm/tlb.h > +++ b/arch/arm/include/asm/tlb.h > @@ -149,7 +149,8 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb) > > static inline void > arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, > - unsigned long start, unsigned long end) > + unsigned long start, unsigned long end, > + bool lazy) > Thanks for the patch, Michal. However, it would be nice to do it tranparently without asking new flags from users. When I read tlb_gather_mmu's description, fullmm is supposed to be used only if there is no users and full address space. That means we can do it API itself like this? void arch_tlb_gather_mmu(...) tlb->fullmm = !(start | (end + 1)) && atomic_read(&mm->mm_users) == 0;
next prev parent reply other threads:[~2017-11-13 0:28 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-07 9:54 [RESEND PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB entry Wang Nan 2017-11-07 10:09 ` Michal Hocko 2017-11-10 0:19 ` Minchan Kim 2017-11-10 10:15 ` Michal Hocko 2017-11-10 12:26 ` [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy (was: Re: [RESEND PATCH] mm, oom_reaper: gather each vma to prevent) " Michal Hocko 2017-11-13 0:28 ` Minchan Kim [this message] 2017-11-13 9:51 ` Michal Hocko 2017-11-14 1:45 ` Minchan Kim 2017-11-14 7:21 ` Michal Hocko 2017-11-15 0:12 ` Minchan Kim 2017-11-15 8:14 ` Michal Hocko 2017-11-16 0:44 ` Minchan Kim 2017-11-16 9:19 ` Michal Hocko 2017-11-15 17:33 ` Will Deacon 2017-11-16 9:20 ` Michal Hocko 2017-11-20 14:24 ` Will Deacon 2017-11-20 16:04 ` [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy Michal Hocko 2017-11-22 19:30 ` Will Deacon 2017-11-23 6:18 ` Minchan Kim
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20171113002833.GA18301@bbox \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).