signal/sig_dispatch: Add signal action, if task is in system call#8740
Conversation
|
There might still be a problem with this fix as well. The syscall entry modifies the user context, and so does up_schedule_sigaction. This needs more testing still. |
|
@xiaoxiang781216 I'll just revert all my changes to get the old functionality back / get rid of the regression. I need to do more homework on how the signal delivery with sigwait() actually works in NuttX to fix this properly. It seems the critical combination is sigwait() and its friends combined with CONFIG_LIB_SYSCALL. I believe some new functionality is needed to handle this case. The problem seems to be that sigwait() is abandoned at once, if a pending signal is waiting, masked or not. |
The _unmasked_ signal action was never added if the task is in system call and waiting for (a different) signal. This fixes deliver especially for default signal actions / unmaskable signals, like SIGTERM.
|
The sigwait test now works with system calls enabled as well, with icicle:pnsh: spawn_execattrs: Setting policy=2 priority=100 for pid=4 Tclock_gettime: clock_id=0 Also killing task when the task is in sleep() works: task_spawn: name=hello entry=0x800496f0 file_actions=0x800c2230 attr=0x800c2238 argv=0x800c2320 hello [5:100] Hello is simply: |
Summary
This fixes regression found in #8605. Only the signal action should be queued when in system call, the signal should not be sent and pended which results in the user app receiving it twice.
Impact
Fix regression from #8605
Testing
icicle:nsh / pnsh + ostest and https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/timer_settime/9-2.c