linux-kernel - Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

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]

Date:	Wed, 24 Sep 2014 16:04:09 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Will Deacon <Will.Deacon@....com>,
	Nathan Lynch <nathan_lynch@...tor.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Christopher Covington <cov@...eaurora.org>,
	Doug Anderson <dianders@...omium.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Mark Rutland <Mark.Rutland@....com>,
	Sonny Rao <sonnyrao@...omium.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code
 consolidation

On Wed, Sep 24, 2014 at 03:52:57PM +0100, Russell King - ARM Linux wrote:
> On Wed, Sep 24, 2014 at 03:45:41PM +0100, Catalin Marinas wrote:
> > On Mon, Sep 22, 2014 at 11:30:23PM +0100, Russell King - ARM Linux wrote:
> > > I raised a while back with Will whether there's much point to having
> > > this on ARM.  While it's useful for virtualisation, the majority of
> > > 32-bit ARM doesn't run virtualised.
> > 
> > This has nothing to do with virtualisation. The main reason we use
> > CNTVCT is to not require kernel binary differences when running the OS
> > as host or guest. But it does _not_ mean that it is only used when
> > running as a guest.
> > 
> > > So there's little point in having the VDSO on the majority of
> > > platforms - it will just add additional unnecessary cycles slowing
> > > down the system calls that the VDSO is designed to try to speed up.
> > 
> > A good reason for VDSO is to avoid a system call for gettimeofday when
> > you can read the clocks source from user space. That's a significant
> > improvement on CPUs like A7, A15.
> 
> I'm *not* arguing against having a VDSO to speed up that crap.  What
> I'm trying to get to the bottom of - something which has been totally
> lost sight of - is what the friggin effect of this stuff is on CPUs
> *without* the architected timer.
> 
> Until I get an answer to what the measured effect is, I'm saying no to
> VDSO on ARM, because - as seems to be the norm - the evaluation job is
> only half done.

I agree.

If there is an overhead (possibly), I think it can be solved in software
maybe by having two VDSO images, one with gettimeofday and one without.
If it's only gettimeofday in VDSO (and signal return still via the
vectors page), we could just avoid inserting it into the user address
space when arch timers aren't present.

On arm64 we expect the presence of the arch timer and didn't bother with
such scenarios.

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