qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 19/34] linux-user: Restart fork() if signals pen


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 19/34] linux-user: Restart fork() if signals pending
Date: Fri, 11 Sep 2015 15:34:48 +0100

On 6 September 2015 at 00:57, Timothy E Baldwin
<address@hidden> wrote:
> If there is a signal pending during fork() the signal handler will
> erroneously be called in both the parent and child, so handle any
> pending signals first.
>
> Signed-off-by: Timothy Edward Baldwin <address@hidden>
> ---
>  linux-user/syscall.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 682090d..1ce381e 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -4731,6 +4731,11 @@ static int do_fork(CPUArchState *env, unsigned int 
> flags, abi_ulong newsp,
>          if ((flags & ~(CSIGNAL | CLONE_NPTL_FLAGS2)) != 0) {
>              return -TARGET_EINVAL;
>          }
> +
> +        if (block_signals()) {
> +            return -TARGET_ERESTARTSYS;
> +        }
> +
>          fork_start();
>          ret = fork();
>          if (ret == 0) {

This is in the fork part of do_fork(). In the clone part we
have some code which does "block all signals, then arrange to
restore them after the pthread_create in both threads". Can
we change that to work with the new block_signals approach?
(I have a feeling that in that case this call to block_signals
ends up being done earlier so it happens in both halves of
the function.)

If we block all signals here, what causes us to unblock them
again?

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]