linux-kernel - Re: waitpid(WNOHANG) should report SIGCHLD-notified signals [Re: [PATCH 09/11] job control: reorganize wait_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110515164705.GI23665@htj.dyndns.org>
Date:	Sun, 15 May 2011 18:47:05 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: waitpid(WNOHANG) should report SIGCHLD-notified signals  [Re:
 [PATCH 09/11] job control: reorganize wait_task_stopped()]

Hello, Jan.

On Sun, May 15, 2011 at 04:40:17PM +0200, Jan Kratochvil wrote:
> It may be not related, I do not inderstand the kernel internals being
> discussed.
> 
> I was told by Roland McGrath that after SIGCHLD of a ptrace even from tracee
> invokes sighandler for that SIGCHLD in the tracer then waitpid(WNOHANG) still
> may return 0 as the signal is not yet ready.  I was not able to reproduce it
> with a testcase myself.

Hmmm... I could easily be wrong but AFAICS that shouldn't happen.  If
you can reproduce the problem, please let us know.

> But if it is a case it should be fixed as there is no later notification when
> to call waitpid(WNOHANG) again.  And sure the debugger cannot busy-loop poll
> it.

But, the current WNOHANG wait is racy.  It's unlikely but definitely
possible for WNOHANG to fail when it's expected to succeed (not the
above case but more convoluted ones).

But, just out of curiosity, is there any reason the ptracer itself
should be doing something other than waitpid() while tracee is
running?  It's not like ptrace requests can be issued during that time
and sleeping waitpid() is way saner mechanism to wait for tracee
events than signal.

Thanks.

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