Re: CVS commit: src/tests/lib/libc/sys

2020-05-14 Thread Taylor R Campbell
> Date: Thu, 14 May 2020 23:36:28 +0200
> From: Kamil Rytarowski 
> 
> If a signal would not reach the child process (as it is ignored or
> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
> checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX.
> Race free signals could be maybe possible, but with some design rethinking.

I don't understand -- are you saying that if I mask SIGCHLD, e.g. with
sigprocmask(SIG_BLOCK), then because sigprop[SIGCHLD] has SA_IGNORE
set, any SIGCHLD signals will be discarded while I have it masked?

This can't be right, so either I misunderstood what you're saying, or
something else is afoot with the test that is making it flaky, or
there's a bug in the kernel.


Re: CVS commit: src/tests/lib/libc/sys

2020-05-14 Thread Joerg Sonnenberger
On Thu, May 14, 2020 at 11:36:28PM +0200, Kamil Rytarowski wrote:
> On 14.05.2020 23:02, Joerg Sonnenberger wrote:
> > On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
> >> Module Name:   src
> >> Committed By:  kamil
> >> Date:  Thu May 14 19:21:35 UTC 2020
> >>
> >> Modified Files:
> >>src/tests/lib/libc/sys: t_ptrace_fork_wait.h
> >>
> >> Log Message:
> >> Ignore interception of the SIGCHLD signals.
> >>
> >> SIGCHLD once blocked is discarded by the kernel as it has the
> >> SA_IGNORE property. During the fork(2) operation all signals can be
> >> shortly blocked and missed (unless there is a registered signal
> >> handler in the traced child). This leads to a race in this test if
> >> there would be an intention to catch SIGCHLD.
> > 
> > This doesn't sound right. sigprocmask and pthread_sigmask shouldn't
> > affect whether the signal handler is called, only when. Temporarily
> > masking a signal is different from setting it to SIG_IGN.
> > 
> > Joerg
> > 
> 
> I was looking into it and as there is no signal handler for SIGCHLD, the
> signal is discarded.

Sure, but that doesn't really have anything to do with signal blocking.
That's the part that is confusing.

Joerg


Re: CVS commit: src/tests/lib/libc/sys

2020-05-14 Thread Kamil Rytarowski
On 14.05.2020 23:02, Joerg Sonnenberger wrote:
> On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Thu May 14 19:21:35 UTC 2020
>>
>> Modified Files:
>>  src/tests/lib/libc/sys: t_ptrace_fork_wait.h
>>
>> Log Message:
>> Ignore interception of the SIGCHLD signals.
>>
>> SIGCHLD once blocked is discarded by the kernel as it has the
>> SA_IGNORE property. During the fork(2) operation all signals can be
>> shortly blocked and missed (unless there is a registered signal
>> handler in the traced child). This leads to a race in this test if
>> there would be an intention to catch SIGCHLD.
> 
> This doesn't sound right. sigprocmask and pthread_sigmask shouldn't
> affect whether the signal handler is called, only when. Temporarily
> masking a signal is different from setting it to SIG_IGN.
> 
> Joerg
> 

I was looking into it and as there is no signal handler for SIGCHLD, the
signal is discarded.

Another approach to fix the race would be to:

1. Add SIGCHLD signal handler in the traced child.
2. Explicitly masking SIGCHLD in the traced child.

If a signal would not reach the child process (as it is ignored or
masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX.
Race free signals could be maybe possible, but with some design rethinking.



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src/tests/lib/libc/sys

2020-05-14 Thread Joerg Sonnenberger
On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
> Module Name:  src
> Committed By: kamil
> Date: Thu May 14 19:21:35 UTC 2020
> 
> Modified Files:
>   src/tests/lib/libc/sys: t_ptrace_fork_wait.h
> 
> Log Message:
> Ignore interception of the SIGCHLD signals.
> 
> SIGCHLD once blocked is discarded by the kernel as it has the
> SA_IGNORE property. During the fork(2) operation all signals can be
> shortly blocked and missed (unless there is a registered signal
> handler in the traced child). This leads to a race in this test if
> there would be an intention to catch SIGCHLD.

This doesn't sound right. sigprocmask and pthread_sigmask shouldn't
affect whether the signal handler is called, only when. Temporarily
masking a signal is different from setting it to SIG_IGN.

Joerg


Re: CVS commit: src/external/bsd/dhcpcd/dist/src

2020-05-14 Thread Christos Zoulas
In article <95034282-ebf6-c1d5-8bb1-9258ee825...@marples.name>,
Roy Marples   wrote:
>On 10/05/2020 18:58, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun May 10 17:58:16 UTC 2020
>> 
>> Modified Files:
>>  src/external/bsd/dhcpcd/dist/src: dhcpcd.c
>> 
>> Log Message:
>> Add SIGPIPE to the list of dhcpcd affected signals since we sigignore it.
>
>Why?

Because the forked programs from scripts were executed with SIGPIPE blocked.
If that breaks non-kqueue OS's we should just add SIGPIPE to the signal
mask to default for posix_spawn().

christos



Re: CVS commit: src/external/bsd/dhcpcd/dist/src

2020-05-14 Thread Roy Marples

On 10/05/2020 18:58, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Sun May 10 17:58:16 UTC 2020

Modified Files:
src/external/bsd/dhcpcd/dist/src: dhcpcd.c

Log Message:
Add SIGPIPE to the list of dhcpcd affected signals since we sigignore it.


Why?

BTW, this breaks non kqueue OS's so can't be accepted upstream.

Roy