linux-kernel - RE: [PATCH 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack

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: <07BA03A3EAC1A04EA0314E65E59B049B6E70BFB5@BADAG02.ba.imgtec.org>
Date:	Sun, 5 Oct 2014 05:52:49 +0000
From:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
	Zubair Kakakhel <Zubair.Kakakhel@...tec.com>,
	"david.daney@...ium.com" <david.daney@...ium.com>,
	"paul.gortmaker@...driver.com" <paul.gortmaker@...driver.com>,
	"davidlohr@...com" <davidlohr@...com>,
	"macro@...ux-mips.org" <macro@...ux-mips.org>,
	"chenhc@...ote.com" <chenhc@...ote.com>,
	"zajec5@...il.com" <zajec5@...il.com>,
	James Hogan <James.Hogan@...tec.com>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"alex@...x-smith.me.uk" <alex@...x-smith.me.uk>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"blogic@...nwrt.org" <blogic@...nwrt.org>,
	"jchandra@...adcom.com" <jchandra@...adcom.com>,
	Paul Burton <Paul.Burton@...tec.com>,
	Qais Yousef <Qais.Yousef@...tec.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
	Markos Chandras <Markos.Chandras@...tec.com>,
	"manuel.lauss@...il.com" <manuel.lauss@...il.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"lars.persson@...s.com" <lars.persson@...s.com>
Subject: RE: [PATCH 2/3] MIPS: Setup an instruction emulation in VDSO
 protected page instead of user stack

From: Peter Zijlstra [peterz@...radead.org]:

>On Fri, Oct 03, 2014 at 08:17:30PM -0700, Leonid Yegoshin wrote:

>> --- a/arch/mips/include/asm/switch_to.h
> >+++ b/arch/mips/include/asm/switch_to.h

>Why raw_smp_processor_id() and why evaluate it 3 times, sure compilers
>can be expected to do some CSE but something like:
>
>        int cpu = smp_processor_id();
>
>        if ( ... [cpu] ...)
>
>is far more readable as well.

Sure. But may be it has sense to use raw_smp_processor_id() due to elevated preemption counter.

>> +     flush_vdso_page();                                              \

>So what I didn't see is any talk about the cost of this. Surely a TLB
>flush isn't exactly free.

Well, flush_vdso_page() uses a local version of TLB page flushing and it is cheap 'per se' in comparison with system-wide.
And I take precautions to flush only if it matches the same memory map, so it is the situation then one pthread on some map is replaced by some pthread on the same map on the same CPU.
So, it flushes only after real use in previous pthread of that map.

However, some performance loss can be expected due to killing TLB.
In low-end cores, with small TLB array we can expect that this TLB can be kicked off anyway after context switch.
In high end cores we should expect FPU unit available and float point emulation can be very rare (un-normalized operations or so).

The only question is a middle line which has enough TLB (32 or more) but may have no float point processor. However, the emulation itself is very slow and it is natural to expect performance degradation because of float point emulation here in much higher degree than possible penalty due to early loss of TLB element.

--
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/