Breno Leitao <lei...@debian.org> writes:
> Hello Michael,
>
> On 08/06/2018 08:06 AM, Michael Ellerman wrote:
>> Breno Leitao <lei...@debian.org> writes:
>>
>>> diff --git a/tools/testing/selftests/powerpc/harness.c
>>> b/tools/testing/selftests/powerpc/harness.c
>>> index 66d31de60b9a..06c51e8d8ccb 100644
>>> --- a/tools/testing/selftests/powerpc/harness.c
>>> +++ b/tools/testing/selftests/powerpc/harness.c
>>> @@ -85,13 +85,16 @@ int run_test(int (test_function)(void), char *name)
>>> return status;
>>> }
>>>
>>> -static void alarm_handler(int signum)
>>> +static void sig_handler(int signum)
>>> {
>>> - /* Jut wake us up from waitpid */
>>> + if (signum == SIGINT)
>>> + kill(-pid, SIGTERM);
>>
>> I don't think we need to do that here, if we just return then we'll pop
>> out of the waitpid() and go via the normal path.
>
> Correct, if we press ^C while the parent process is waiting at waitpid(),
> then waitpid() syscall will be interrupted (EINTR) and never restarted again
> (unless we set sa_flags = SA_RESTART), thus, the code will restart to execute
> the next instruction when the signal handler is done, as we had skipped
> waitpid().
>
> From a theoretical point of view, the user can press ^C before the process
> executes waitpid() syscall. In this case and the process will not 'skip' the
> waitpid(), which will continue to wait. We can clearly force this behavior
> putting a sleep(1) before waitpid() and pressing ^C in the very first
> second, it will 'skip' the nanosleep() syscall instead of waitpid() which
> will be there, and the ^C will be ignored (thus not calling kill(-pid,
> SIGTERM)).
True.
Though that race also exists vs us registering the SIGINT handler, so
it's basically not solvable, the user can always press ^C before we're
ready.
cheers
