Signals not delivered to correct thread

[prp]

The following test uses rt_sigqueueinfo to send a signal to a thread: vtikoo@7e539ee

When running the test directly, it succeeds:

$ ./rt_sigqueueinfo01
pid=1204
tid within main thread: 1204
errno: 0, Success
tid of child thread: 1205
tst_checkpoint_wake(0)
errno: 0, Success
ret: 0, errno: 0, Success
tid within signal handler: 1205
Received correct signal and data!
ret: 0, errno: 0, Success
rt_sigqueueinfo() was successful

When run with SGX-LKL, it fails as follows:

[[  SGX-LKL ]] libc_start_main_stage2(): Calling app main: rt_sigqueueinfo01
pid=36
tid within main thread: 1
errno: 0, No error information
tid of child thread: 47
tst_checkpoint_wake(0)
errno: 0, No error information
ret: 0, errno: 0, No error information
rt_sigqueueinfo() failed (ret=-1 errno=3 (No such process))

The problem seems to be that the assigned tid for the main thread is inconsistent with the pid.

(cc: @vtikoo @davidchisnall)

[prp]

Ok, the above problem goes away when we remove the syscall bypass for gettid(). (The pid/tid assignment is then still not consistent, but this may be ok.)

The problem then is that the signal is always delivered to the thread calling rt_sigqueueinfo and not the thread whose tid is specified.

The reason is that the code in LKL's handle_signal() does not create a proper stack frame for the signal handler, but rather just calls the handler directly.

For the pending signal to be associated with the correct thread, I suspect that we need to follow the x86 signal handling code, which first creates a stack frame and then invokes the kernel signal delivery.

This may pull in more x86 architecture code into LKL.

[davidchisnall]

I don't think that we need a proper stack frame to have the correct behaviour, we just need to wake up the correct thread and allow it to pull the pending signal off the stack on syscall return. Currently, we are handling all signals for any task on syscall return.

[prp]

@davidchisnall I'm not sure. I think that the correct code path for signal handling is to create a stack frame and associate the pending signal with the correct thread (which can be done on the syscall return path -- for x86 it's done during a user/kernel space transition). The pending signal will then be picked up by the scheduler. I think that the problem with our current implementation is that it just calls the signal handler directly.

[SeanTAllen]

The tgkill LTP should be enabled when this is fixed.

[KenGordon]

This is fixed as of #830 with the test re-enabled in 539b65a

/datadrive/kegordo/sept17/sgx-lkl/build/sgx-lkl-run-oe --hw-debug sgxlkl-miniroot-fs.img /ltp/testcases/kernel/syscalls/rt_sigqueueinfo/rt_sigqueueinfo01 tst_test.c:1117: INFO: Timeout per run is 0h 00m 20s tst_test.c:1136: INFO: No fork support rt_sigqueueinfo01.c:37: PASS: Received correct signal and data! rt_sigqueueinfo01.c:78: PASS: rt_sigqueueinfo() was successful! [ 0.117755] reboot: Restarting system