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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 8 Jun 2011 09:16:20 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	pageexec@...email.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

* pageexec@...email.hu <pageexec@...email.hu> wrote:

> to give you an idea:
> - if a code path executes in 1M or 1K cycles once every hour, then
>   it's not a fast path, it doesn't matter to anyone whether it runs
>   1 or 10 cycles faster or not,
> - if a code path executes in 1M cycles 100 times a second then it's
>   still not a fast path where single cycle speedups would mean anything,
> - now if a code path executes in 1K cycles 100K times a second then
>   suddenly there's a huge multiplier on even single cycle improvements
>   that *may* be measurable and therefore relevant for some users

The thing is, as i explained it before, your claim:

  > a page fault is never a fast path

is simply ridiculous on its face and crazy talk.

Beyond all the reasons why we don't want to touch the page fault path 
we have a working, implemented, tested IDT based alternative approach 
here that is faster and more compartmented so there's no reason 
whatsoever to touch the page fault path. We *do* add code to the page 
fault path in justified cases so this is not an absolute rule, but we 
try to avoid doing it, for all the reasons that me and others 
outlined.

Even if you do not take my word for it, several prominent kernel 
developers told you already that you are wrong, and i also showed you 
the commits that prove you wrong.

Your reply to that was to try to change the topic, laced with 
frequent insults thrown at me. You called me an 'asshole' yet the 
only thing i did was that i argued with you patiently.

Is there *any* point where you are willing to admit that you are 
wrong or should i just start filtering out your emails to save me all 
this trouble? When you comment on technical details you generally 
make very good suggestions so i'd hate to stop listening to your 
feedback, but there's a S/N ratio threshold under which i will need 
to do it ...

Thanks,

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