Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Jun 2016 11:36:44 -0700
From: Andy Lutomirski <>
To: Linus Torvalds <>
Cc: Brian Gerst <>, Peter Zijlstra <>, 
	Oleg Nesterov <>, Andy Lutomirski <>, 
	"the arch/x86 maintainers" <>, Linux Kernel Mailing List <>, 
	"" <>, Borislav Petkov <>, 
	Nadav Amit <>, Kees Cook <>, 
	"" <>, Josh Poimboeuf <>, 
	Jann Horn <>, Heiko Carstens <>
Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 10:56 AM, Linus Torvalds
<> wrote:
> On Fri, Jun 24, 2016 at 10:47 AM, Andy Lutomirski <> wrote:
>> FWIW, your patch is much more lenient than my approach.
> I hate big flag-days - they cause so much pain for everybody. The
> people who get it to work and can test it, can't test all the other
> cases (whether they be drivers or other architectures), so I'd much
> rather implement something that allows a gradual per-architecture
> change from having the thread_info on the stack into having the
> thread_info in the task_struct.
> Bit "let's just change everything at once" patches are fine (and, in
> fact, preferable) when you can test everything in one go. So something
> that can be statically verified (ie "patch makes no semantic
> difference, but changes calling convention or naming, so if it
> compiles it is fine") I much prefer just getting the pain over and
> done with rather than some lingering thing.
> But when it's something where "oops, I broke every other architecture,
> and I can't even test it", I'd much rather do it in a way where each
> architecture can move over to the new model one by one.


To clarify, though: I wasn't planning on changing all arches at once.
 I'm just saying that, for arches that switch over, they get a single
core definition of thread_info.  That way, when someone (probably
named Peter) decides down the road to move, say, thread_info::cpu into
task_struct proper to optimize cache line layout, they won't need to
do it for every architecture.

Also, I want to give people an incentive to finally move their crap
out of struct thread_info and into struct thread_struct.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.