On Fri, Jun 24, 2016 at 7:41 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski <l...@amacapital.net> wrote: >>> >>> 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. > > Ok, I'e pushed out the cleanups (and all the pulls that always come in > on Friday afternoon - gaah, I shouldn't have tried doing this on a > Friday). > > I'm attaching the current left-over patch that actually changes > things. It's obviously a composite, and includes your "remove > stack_smp_processor_id()" thing etc, so it's not meant to be used > as-is, but it does seem to work. > > Interestingly, it seems pretty clean too, removing more lines than it > adds (despite the fact that it adds a new config option), and > generally making things prettier rather than the reverse. > > That's always a good sign.
I rebased my series onto your tree and then rebased this thing onto my series, tweaked it some, and split it up a bit. My version works a bit differently (thread_info has a single element if the new option is set) but is otherwise more or less your code. It seems to work. https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=01ac3242f314405c1bac0f820ec3575a850509d3 https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=87194cac139aebecec89a68eff719ab44f0469a2 On top of *that*, I taught the kernel to free stacks in release_task and to cache stacks if vmalloced. That still blows up: when cryptomgr_test calls do_exit during boot, do_exit calls exit_notify, which observes that the task state is TASK_DEAD and thus calls release_task on itself and goes boom. Linus, Oleg, help? How am I supposed to quickly free the stack if the task goes through this code path? In fact, why does this work on current kernels? After all, can't schedule() indicates an RCU grace period? In principle, what prevents delayed_put_task_struct from deleting the running stack before scheduling? My kludged up patch that only early-releases the stack if release_task is called from a different task is here: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=2327ca2ab3d634d120ea185e737fef2e4e9cf012 Ick.
