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
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
