Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 24 Jun 2016 14:34:59 -0700 | Subject | Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) |
| |
On Fri, Jun 24, 2016 at 2:32 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, Jun 24, 2016 at 2:25 PM, Andy Lutomirski <luto@amacapital.net> 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? >
Works for me. I'll see whether my vmap patches still apply and, if needed, rebase and send a v5.
--Andy
| |