On 6/9/23 11:18, Eelco Chaudron wrote:
>
>
> On 8 Jun 2023, at 21:16, Ilya Maximets wrote:
>
>> The signal_fds pipe and wevent are a mechanism to wake up the process
>> after it received a signal and stored the number for the future
>> processing. They are not intended for inter-process communication.
>> However, in the current code, descriptors are not closed on fork().
>>
>> The main scenario where we use fork() is a monitor process. Monitor
>> doesn't actually use poll loops and doesn't wait on the descriptor.
>> But when a child process is killed, it (child) sends a byte to itself,
>> then it wakes up due to POLLIN on the pipe and terminates itself after
>> processing all the callbacks. The byte stays unread. And the pipe is
>> still open in the monitor process. When child dies, the monitor wakes
>> up and forks again. New child inherits the same pipe that still
>> contains unread data. This data is never read, so the child will
>> constantly wake itself up for no reason.
>>
>> Interestingly enough raise(SIGSEGV) doesn't immediately kill the
>> process. The execution continues til the end of a signal handler,
>> so we're still able to write a byte to a pipe even in this case.
>> Presumably because we don't have SA_NODEFER.
>>
>> Fix the issue by re-creating the pipe/event on fork. This way
>> every new child will have its own notification channel and will
>> not wake up any other processes.
>>
>> There was already an attempt to fix the issue, but it didn't get a
>> follow up (see the reported-at tag). This is an alternative solution.
>>
>> Fixes: ff8decf1a318 ("daemon: Add support for process monitoring and
>> restart.")
>> Reported-at:
>> https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/
>> Signed-off-by: Ilya Maximets <[email protected]>
>
>
> The changes look good to me.
>
> Only tested on linux, and looking up the APIs on Windows, that part seems
> fine.
>
> Acked-by: Eelco Chaudron <[email protected]>
Thanks! Applied and backported down to 2.17.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
