https://bugzilla.kernel.org/show_bug.cgi?id=205183

Daniel Axtens (dja@axtens.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dja@axtens.net

--- Comment #2 from Daniel Axtens (dja@axtens.net) ---

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.