On 10/3/24 3:32 PM, Alexei Starovoitov wrote:
On Thu, Oct 3, 2024 at 1:44 PM Yonghong Song <yonghong.song@xxxxxxxxx> wrote:
Looks like the idea needs more thought.
in_task_stack() won't recognize the private stack,
so it will look like stack overflow and double fault.
do you have CONFIG_VMAP_STACK ?
Yes, my above test runs fine withCONFIG_VMAP_STACK. Let me guard private stack support with
CONFIG_VMAP_STACK for now. Not sure whether distributions enable
CONFIG_VMAP_STACK or not.
Good! but I'm surprised it makes a difference.
That only for the test case I tried. Now I tried the whole bpf selftests
with CONFIG_VMAP_STACK on. There are still some failures. Some of them
due to stack protector. I disabled stack protector and then those stack
protector error gone. But some other errors show up like below:
[ 27.186581] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 27.187480] BUG: unable to handle page fault for address: ffff888109572800
[ 27.188299] #PF: supervisor instruction fetch in kernel mode
[ 27.189085] #PF: error_code(0x0011) - permissions violation
or
[ 27.736844] BUG: unable to handle page fault for address: 0000000080000000
[ 27.737759] #PF: supervisor instruction fetch in kernel mode
[ 27.738631] #PF: error_code(0x0010) - not-present page
[ 27.739455] PGD 0 P4D 0
[ 27.739818] Oops: Oops: 0010 [#1] PREEMPT SMP PTI
...
Some further investigations are needed.
Please still root cause the crash without VMAP_STACK.
Sure. Let me investigate cases with VMAP_STACK first and
then will try to look at it without VMAP_STACK.
We need to do a lot more homework here before proceeding.
Look at arch/x86/kernel/dumpstack_64.c
At least we need new stack_type for priv stack.
stack_type_unknown doesn't inspire confidence.
Need to make sure stack trace is still reliable with priv stack.
Though it may look appealing from performance pov.
We may need to go back to r9 approach with push/pop around calls,
since that is surely keeping unwinder happy
while this approach will have to teach unwinder.
Good point.
