linux-kernel - Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)

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]

Date:	Thu, 9 Apr 2009 11:41:24 -0500
From:	Kumar Gala <galak@...nel.crashing.org>
To:	oleg@...hat.com, sukadev@...ux.vnet.ibm.com
Cc:	linux-kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)


On Apr 9, 2009, at 10:43 AM, Kumar Gala wrote:

> I'm seeing some weird behavior in 2.6.30-rc1 that didn't exist in  
> 2.6.29.  We have a slightly older LTP version (20080131) that we run  
> on some embedded PPC boards.  If I run the syscall tests on 2.6.29  
> things pass as expected.  W/2.6.30-rc1 I start seeing a slew of  
> processes that are "defunct".  I was able to trim down the tests to  
> the following ones (the recv01 test will become defunct):
>
> ptrace01 ptrace01
> ptrace02 ptrace02
> ptrace03 ptrace03
>
> recv01 recv01
>
> I'm able to reproduce this in a simulator, and am working on  
> bisecting it down now.
>
> Was wondering if there was anything ptrace related that went in that  
> could possible cause this?

So I was able to bisect this down to:

commit b3bfa0cba867f23365b81658b47efd906830879b
Author: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Date:   Thu Apr 2 16:58:08 2009 -0700

     signals: protect cinit from blocked fatal signals

     Normally SIG_DFL signals to global and container-init are dropped  
early.
     But if a signal is blocked when it is posted, we cannot drop the  
signal
     since the receiver may install a handler before unblocking the  
signal.
     Once this signal is queued however, the receiver container-init  
has no way
     of knowing if the signal was sent from an ancestor or descendant
     namespace.  This patch ensures that contianer-init drops all  
SIG_DFL
     signals in get_signal_to_deliver() except SIGKILL/SIGSTOP.

     If SIGSTOP/SIGKILL originate from a descendant of container-init  
they are
     never queued (i.e dropped in sig_ignored() in an earler patch).

     If SIGSTOP/SIGKILL originate from parent namespace, the signal is  
queued
     and container-init processes the signal.

     IOW, if get_signal_to_deliver() sees a sig_kernel_only() signal  
for global
     or container-init, the signal must have been generated internally  
or must
     have come from an ancestor ns and we process the signal.

     Further, the signal_group_exit() check was needed to cover the  
case of a
     multi-threaded init sending SIGKILL to other threads when doing  
an exit()
     or exec().  But since the new sig_kernel_only() check covers the  
SIGKILL,
     the signal_group_exit() check is no longer needed and can be  
removed.

     Finally, now that we have all pieces in place, set  
SIGNAL_UNKILLABLE for
     container-inits.

     Signed-off-by: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
     Cc: Oleg Nesterov <oleg@...sign.ru>
     Cc: Roland McGrath <roland@...hat.com>
     Cc: "Eric W. Biederman" <ebiederm@...ssion.com>
     Cc: Daniel Lezcano <daniel.lezcano@...e.fr>
     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
     Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

This is highly reproducible for me so I can add any debug code you'd  
like.  I'm not 100% clear on what it is that causes ps to report  
<defunct>:

  2447 ttyS0    00:00:00 recv01 <defunct>
  2449 ttyS0    00:00:00 recvfrom01 <defunct>
  2451 ttyS0    00:00:00 recvmsg01 <defunct>

If I revert the commit on v2.6.30-rc1 these processes die properly and  
things run as expected.

- k
--
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/