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+55aFxrWx5pFN3LseaKpUHtB6nqXtkgP84seU3pjys-kq7utQ@mail.gmail.com>
Date:	Thu, 7 Apr 2016 09:39:02 -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 4:19 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> People objected against the fixed size scheme, but it being possible to
> get a fixed TCB offset and reduce indirections is a big win IMO.

Guys, I'm going to just make an executive decision here, because this
whole "fixed vs some strange size that is a superset of kernel and
user mode knowledge" discussion has been going on for too long.

Here's the executive decision: I will not merge anything that doesn't
have a (small) fixed size as far as the kernel is concerned.

Why?

I don't think there is *any* possible reason for the kernel to care
about the size. There will be no future extensions. The kernel will
not magically start doing bigger things, and change more fields, or
anything like that.

Put another way: if the interface cannot be designed so that the
kernel simply DOES NOT HAVE TO CARE about the rest of the crap, I will
not merge this patch series. Ever.

So I don't want to hear more idiotic emails about "extensible sizes".
The people who want to push this interface had better be able to show
that the kernel will never care about what user space does, and *all*
the kernel has to do is to invalidate a single field when a thread is
moved.

In other words:

 - get rid of the stupid "abi features" bitfield. Anybody who feels it
is needed had better take a deep breath and ask themselves why.

 - that leaves us with *one* single 32-bit field that the kernel cares
about: "cpu_id".

 - we specify that the *only* thing the kernel will ever do is that single

      put_user(raw_smp_processor_id(), &t->tlabi->cpu_id)

   and absolutely nothing else.

End result?  That damn data structure is 32 bits. No more, no less.
I'm perfectly happy to make a strict requiremnt that it is some
16-byte aligned thing, and we can add padding values, but quite
frankly, I'm not really sure even that is required.

And if the kernel ever has to care about anything else, I say "no".

Can anybody give a *coherent* and actual *real* reason why the kernel
would ever care about anything else?

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.

                      Linus