Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

[Linus Torvalds]

On Fri, Jun 24, 2016 at 2:25 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>
> What's the prognosis for this patch?  Should I queue up all the pieces
> and send them out after the vmap-stack thing?

I'm going to split this thing up and apply the "semantically null"
cleanup parts.

For example, this patch makes it clear that our current
"alloc_thread_info_node()" this is entirely insane.

We literally do:

        ti = alloc_thread_info_node(tsk, node);
        ...
        tsk->stack = ti;

and

        arch_release_thread_info(tsk->stack);
        free_thread_info(tsk->stack);

and the pure *confusion* there is just crazy. We're talking
"tsk->stack", but then we talk about freeing and allocating
"thread_info"

So I'll apply the whole "rename 'free_thread_info()' into
'free_thread_stack()'" part independently of anything else. It will
not change any semantics at all, since we currently have "tsk->stack
== thread_info", but it's too ugly to live, and it will then make the
patches that *do* change semantics much clearer and easier to see.

So let me get the pure semantic patches done, and then for 4.8 when we
do the things that actually change real meaning we'll have a sane
base. Ok?

                   Linus