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

[Andy Lutomirski]

On Fri, Jun 24, 2016 at 7:41 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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.