Re: RFC: i386: kill !4KSTACKS

[Jan Kiszka <jan.kiszka@googlemail.com>]

2005/9/6, Giridhar Pemmasani <giri@lmc.cs.sunysb.edu>:
> Andi Kleen wrote:
> 
> > AFAIK with interrupt stacks it shouldn't be a big issue to switch
> > to a private bigger stack. ndiswrapper just needs to have its own private
> > way to do "current" which accesses thread_info at the bottom of the stack.
> 
> I am developer of ndiswrapper and just caught up with this discussion. I am
> interested in providing private stack for ndiswrapper. I am not familiar
> with linux kernel internals to understand your proposal. Could you give me
> details please: If you can give a rough sketch of idea, I can implement it.
> Better yet, if you (or anyone else) can provide an implementation (not
> necessarily against ndsiwrapper, but a proof of concept), it will be
> greatly appreciated - this should also help any other projects that need
> more than 4k stack.
> 

You may take a look at how the IRQ stacks work on x86, e.g.
http://lxr.linux.no/source/arch/i386/kernel/irq.c#L48

The idea of switching stacks first sounds appealing, but it is not
that trivial. The tricky part comes with current/current_thread_info.
After you switched to a private stack and called some Windows driver
function, that code may call back to the ndiswrapper API which, in
turn, may jump into some kernel functions. If that kernel code calls
current_thread_info while your differently sized stack is active,
current_thread_info will not be able to evaluate a correct thread_info
address (see http://lxr.linux.no/source/include/asm-i386/thread_info.h#L88).

The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging, as you will
likely not want to create a new stack on each switching point. Rather,
maintaining them per context (IRQ, tasklet, kernel thread, user
process, <stuff I forgot>) is required in order to save memory and
avoid shortages in atomic contexts.

Jan