Virtually mapped stacks

[mpe]

Looks like virtually mapped stacks are coming soon for x86:

https://lkml.org/lkml/2016/6/15/1064

There are some generic changes, but the bulk is arch specific. We will need to enable for power.

[mikey]

FWIW nice lwn article here:
https://lwn.net/SubscriberLink/692208/2e5521b846f9a3ea/

[bsingharora]

Spent some time looking at what we might need to do

The top things are:

1. Move allocations to vmalloc()
2. Guard page/fault handling. I think we should never hit a double fault, unless we get a real overflow with vmap'd stacks
3. Deal with real mode - discussed with @mpe . Basically use either the current stack pointer saved in paca (real address) or use a small real mode stack.

The rest should be common - fork/exit bits and accounting.

The value of this feature will go down once we get FSTACK_PROTECTOR functional again. But in the meanwhile we could move thread_info out of the stack and do some other things.

A disadvantage of this feature on power would be increased memory utilization with 64K being used instead of 16K per stack.

[chleroy]

First step is the implementation of THREAD_INFO_IN_TASK, see #187
Once the above is merged, it open the door to implement VMAP_STACK

[chleroy]

The challenge is to access vm data from exception handlers entry.

Today, exception prolog determines stack physical address then saves registers like SRR0, SRR1, DAR, ... into the stack before switching back to MMU ON.

For using VM stack, we need to re-activate DATA translation earlier. This implies being able to service DTLB misses without jeopardising in-progress exception prolog, which means:

• Using in DTLB miss different scratch registers than the ones used by exception prolog
• Saving SRR0, SRR1 and DAR out of stack before re-activating DATA translation.

[chleroy]

On the 8xx, the HW assistance serie has allowed us to reduce to two the number of scratch registers used in DLTB miss. As exception prolog uses SPRG0 and SPRG1, we can use M_TW and DAR for DTLB miss.

We should be able to store SRR0, SRR1 and DAR in the thread_struct before re-activating Data translation, then copy them to stack after.

[chleroy]

The challenge is to identify and fix all places where stack is used in an unsafe way.
For that, the implementation of #147 would help.

One exemple: the max7301 GPIO driver performs SPI transfers with spi_write() and spi_read() with buffer on stack. This works today because stack is DMA-safe , but fails with Virtually mapped stacks.

[chleroy]

First attempt at https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=128398

For the time being, it hangs in lkdtm EXHAUST_STACK test.

The tricky thing is that r1 is updated with stwu. But if the store fails, r1 is not updated at the time the fault exception is taken, so the handler cannot know that r1 is out of bounds.

[chleroy]

Working series at https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=129901

Covers 8xx and book3s/32

[chleroy]

Merged in v5.6 for 8xx (linuxppc/linux@99b2291) and book3s/32 (linuxppc/linux@cd08f10)