linux-kernel - Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4DECF6E8.19026.131F1F1F@pageexec.freemail.hu>
Date:	Mon, 06 Jun 2011 17:48:56 +0200
From:	pageexec@...email.hu
To:	Ingo Molnar <mingo@...e.hu>
CC:	Andrew Lutomirski <luto@....edu>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Jesper Juhl <jj@...osbits.net>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Jan Beulich <JBeulich@...ell.com>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	Mikael Pettersson <mikpe@...uu.se>,
	Andi Kleen <andi@...stfloor.org>,
	Brian Gerst <brgerst@...il.com>,
	Louis Rilling <Louis.Rilling@...labs.com>,
	Valdis.Kletnieks@...edu
Subject: Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls

On 6 Jun 2011 at 17:26, Ingo Molnar wrote:

> 
> * pageexec@...email.hu <pageexec@...email.hu> wrote:
> 
> > > > a page fault is never a fast path, after all the cpu has just 
> > > > taken an exception (vs. the syscall/sysenter style actually 
> > > > fast user->kernel transition) and is about to make page table 
> > > > changes (and possibly TLB flushes).
> > >
> > > Sure it is.  It's a path that's optimized carefully and needs to 
> > > be as fast as possible.  Just because it's annoyingly slow 
> > > doesn't mean we get to make it even slower.
> > 
> > sorry, but stating that the pf handler is a fast path doesn't make 
> > it so ;) [...]
> 
> Are you talking about the Linux kernel?

yes, what else? ;)

> FYI, incredible amount of work has gone into making pagefaults as 
> fast and scalable as possible.

i wasn't talking about scalability (it's irrelevant anyway here), only
speed. you're the man with the (in)famous measuring stick, tell me how
many cycles it takes to serve a C-O-W fault or instantiation of an anon
page and a file page (both cached and non-cached). then stick a few well
predicted conditional branches in that path (something that wouldn't
actually happen with my code but let's play this out fully) and show me
measured differences. then we'll talk about the 'impact on fast path'.

> If you are following Linux kernel development you'd have to be
> virtually blind to not see all that effort. 

nice attempt to question me but it won't get you anywhere (didn't i just
tell you to heed your own advice?). case in point, i'd fixed the anon_vma
refcount leak (exploitable and silently fixed as usual in mainline) a
few months before you guys did. just by reading the code. now show me
that you know your stuff around and can find the commit i'm talking about.
unless of course you are not "following Linux kernel development" and
are "virtually blind to not see all that effort".

> You claiming that pagefaults are a slow-path and ridiculing those who 
> point out your mistake does not make it a slowpath.

you must have realized by now that slow/fast path in this context were
relative to int xx vs. pf processing. and i'm yet to receive the numbers
that show how much faster the latter is processed than the former and why
sticking a few well predictable conditional jumps (no really, they would
not be there, but let's assume they are) shows a measurable impact on
these all so fast pf paths.

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