linux-kernel - Re: [PATCH] mm: Flush the TLB for a single address in a huge page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150723164921.GH27052@e104818-lin.cambridge.arm.com>
Date:	Thu, 23 Jul 2015 17:49:21 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	Dave Hansen <dave.hansen@...el.com>,
	David Rientjes <rientjes@...gle.com>,
	linux-mm <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [PATCH] mm: Flush the TLB for a single address in a huge page

On Thu, Jul 23, 2015 at 03:13:03PM +0100, Andrea Arcangeli wrote:
> On Thu, Jul 23, 2015 at 11:49:38AM +0100, Catalin Marinas wrote:
> > On Thu, Jul 23, 2015 at 12:05:21AM +0100, Dave Hansen wrote:
> > > On 07/22/2015 03:48 PM, Catalin Marinas wrote:
> > > > You are right, on x86 the tlb_single_page_flush_ceiling seems to be
> > > > 33, so for an HPAGE_SIZE range the code does a local_flush_tlb()
> > > > always. I would say a single page TLB flush is more efficient than a
> > > > whole TLB flush but I'm not familiar enough with x86.
> > > 
> > > The last time I looked, the instruction to invalidate a single page is
> > > more expensive than the instruction to flush the entire TLB. 
[...]
> > Another question is whether flushing a single address is enough for a
> > huge page. I assumed it is since tlb_remove_pmd_tlb_entry() only adjusts
[...]
> > the mmu_gather range by PAGE_SIZE (rather than HPAGE_SIZE) and
> > no-one complained so far. AFAICT, there are only 3 architectures
> > that don't use asm-generic/tlb.h but they all seem to handle this
> > case:
> 
> Agreed that archs using the generic tlb.h that sets the tlb->end to
> address+PAGE_SIZE should be fine with the flush_tlb_page.
> 
> > arch/arm: it implements tlb_remove_pmd_tlb_entry() in a similar way to
> > the generic one
> > 
> > arch/s390: tlb_remove_pmd_tlb_entry() is a no-op
> 
> I guess s390 is fine too but I'm not convinced that the fact it won't
> adjust the tlb->start/end is a guarantees that flush_tlb_page is
> enough when a single 2MB TLB has to be invalidated (not during range
> zapping).
> 
> For the range zapping, could the arch decide to unconditionally flush
> the whole TLB without doing the tlb->start/end tracking by overriding
> tlb_gather_mmu in a way that won't call __tlb_reset_range? There seems
> to be quite some flexibility in the per-arch tlb_gather_mmu setup in
> order to unconditionally set tlb->start/end to the total range zapped,
> without actually narrowing it down during the pagetable walk.

You are right, looking at the s390 code, tlb_finish_mmu() flushes the
whole TLB, so the ranges don't seem to matter. I'm cc'ing the s390
maintainers to confirm whether this patch affects them in any way:

https://lkml.org/lkml/2015/7/22/521

IIUC, all the functions touched by this patch are implemented by s390 in
its specific way, so I don't think it makes any difference:

pmdp_set_access_flags
pmdp_clear_flush_young
pmdp_huge_clear_flush
pmdp_splitting_flush
pmdp_invalidate

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/