https://bugzilla.kernel.org/show_bug.cgi?id=205183
Daniel Axtens ([email protected]) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Daniel Axtens ([email protected]) --- Hi, I'm starting to have a look at this for Daniel B. So looking at the fault that fails, I see that it's a fault with the NIP in the _kernel_ that fails, rather than in userspace. Dumping stack we see: [ 118.917679] Call Trace: [ 118.917715] [c00000007b457820] [c000000000b71538] dump_stack+0xbc/0x104 (unreliable) [ 118.917719] [c00000007b457860] [c00000000006e8f0] __do_page_fault+0x860/0xf90 [ 118.917721] [c00000007b457940] [c00000000000af68] handle_page_fault+0x10/0x30 [ 118.917725] --- interrupt: 301 at handle_rt_signal64+0x180/0x13a0 LR = handle_rt_signal64+0x148/0x13a0 [ 118.917726] [c00000007b457d30] [c000000000023d30] do_notify_resume+0x2e0/0x410 [ 118.917728] [c00000007b457e20] [c00000000000e4c4] ret_from_except_lite+0x70/0x74 I'm still debugging, but it looks like handle_rt_signal64 attempts to reserve a stack frame for the signal, but computes a stack address that sits outside valid stack space. Then when writing to it, it pagefaults, and because it's not a userland NIP, it refuses to expand the stack. I'll keep you up to date. Regards, Daniel A -- You are receiving this mail because: You are watching the assignee of the bug.
