linux-kernel - Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

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: <CA+55aFyB6CPNiMKGWoaV7vxFWWBTgqOTqG4u2aNnq6uq1cHWZA@mail.gmail.com>
Date:	Thu, 7 Apr 2016 09:52:11 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Florian Weimer <fweimer@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-api <linux-api@...r.kernel.org>,
	Paul Turner <pjt@...gle.com>, Andrew Hunter <ahh@...gle.com>,
	Andy Lutomirski <luto@...capital.net>,
	Andi Kleen <andi@...stfloor.org>,
	Dave Watson <davejwatson@...com>, Chris Lameter <cl@...ux.com>,
	Ben Maurer <bmaurer@...com>, rostedt <rostedt@...dmis.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Josh Triplett <josh@...htriplett.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Boqun Feng <boqun.feng@...il.com>
Subject: Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number
 of running thread

On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Because if not, then this discussion is done for. Stop with the
> f*cking idiotic "let's look at some kernel size and user-space size
> and try to match them up". The kernel doesn't care. The kernel MUST
> NOT care. The kernel will touch one single word, and that's all the
> kernel does, and user space had better be able make up their own
> semantics around that.

.. and btw - if people aren't sure that that is a "good enough"
interface, then I'm sure as hell not going to merge that patch anyway.
Andy mentions rseq. Yeah, I'm not going to merge anything where part
of the discussion is "and we might want to do something else for X".

Either the suggested patches are useful and generic enough that people
can do this, or they aren't.

If people can agree that "yes, this whole cpu id cache is a great
interface that we can build up interesting user-space constructs
around", then great. Such a new kernel interface may be worth merging.

But if people cannot be convinced that it is sufficient, then I don't
want to merge some half-arsed interface that generates these kinds of
discussions.

So the fact that currently makes me go "no way will I merge any of
this" is the very fact that these discussions continue and are still
going on.

                Linus