Re: [PATCH] fix handling of SIGCHILD from reaped child

[Oleg Nesterov]

On 02/20, KAMEZAWA Hiroyuki wrote:
>
> SUSv3 says
> ==
> if SIGCHLD is blocked, if wait() or waitpid() return because the status of a
> child process is available, any pending SIGCHLD signal shall be cleared unless
> the status of another child process is available.
> ==

Ingo, Roland, should we implement this?

I must admit, I don't understand the text above, "blocked" is per-thread, but
wait() is process wide (any sub-thread can reap a dead child).

> -static int collect_signal(int sig, struct sigpending *list, siginfo_t *info)
> +static int collect_signal(int sig, struct sigpending *list, siginfo_t *info, pid_t checkpid)
>  {
> -	list_for_each_entry(q, &list->list, list) {
> -		if (q->info.si_signo == sig) {
> -			if (first) {
> -				still_pending = 1;
> -				break;
> +	if (unlikely(checkpid)) {
> +		list_for_each_entry(q, &list->list, list) {
> +			if (q->info.si_signo == sig) {
> +			    if (q->info.si_pid == checkpid)
> +					first = q;
> +				else
> +					still_pending = 1;
> +			}
> +		}
> +	} else {
> +		list_for_each_entry(q, &list->list, list) {
> +			if (q->info.si_signo == sig) {
> +				if (first) {
> +					still_pending = 1;
> +					break;
> +				}
> +				first = q;
>  			}
> -			first = q;

I'd suggest to make a separate function, but not complicate collect_signal().

> --- linux-2.6.20-devel.orig/kernel/exit.c
> +++ linux-2.6.20-devel/kernel/exit.c
> @@ -1252,8 +1252,12 @@ static int wait_task_zombie(struct task_
>  		}
>  		write_unlock_irq(&tasklist_lock);
>  	}
> -	if (p != NULL)
> +	if (p != NULL) {
>  		release_task(p);
> +		/* if we received sigchild from "p" and p is released,
> +		   we remove sigchild from it. */

current may be ptracer, not a parent. Should be ok, clear_stale_sigchild(pid)
can't have a false positive (until we have namespace for pid_t), but the comment
is misleading a bit.

> +		clear_stale_sigchild(current, retval);

But we are not checking that SIGCHLD is blocked?

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/