On Sat, Jun 25, 2016 at 4:19 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > 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 Maybe I'm misunderstanding the role of release_task. It looks like there's this path in the scheduler I can borrow: if (unlikely(prev_state == TASK_DEAD)) { With a kludge in place to free the stack in there and release_task and __put_task_struct, whichever is first, I get a nice speedup. Benchmarks coming later on. Can I rely on that code path always being called? --Andy -- 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
