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

public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed

* LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
@ 2009-04-09 15:43 Kumar Gala
  2009-04-09 16:41 ` Kumar Gala
  0 siblings, 1 reply; 9+ messages in thread
From: Kumar Gala @ 2009-04-09 15:43 UTC (permalink / raw)
  To: linux-kernel Mailing List

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?

- k

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
  2009-04-09 15:43 LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?) Kumar Gala
@ 2009-04-09 16:41 ` Kumar Gala
  2009-04-09 19:49   ` Sukadev Bhattiprolu
  0 siblings, 1 reply; 9+ messages in thread
From: Kumar Gala @ 2009-04-09 16:41 UTC (permalink / raw)
  To: oleg, sukadev; +Cc: linux-kernel Mailing List, Andrew Morton


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@linux.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@linux.vnet.ibm.com>
     Cc: Oleg Nesterov <oleg@tv-sign.ru>
     Cc: Roland McGrath <roland@redhat.com>
     Cc: "Eric W. Biederman" <ebiederm@xmission.com>
     Cc: Daniel Lezcano <daniel.lezcano@free.fr>
     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
     Signed-off-by: Linus Torvalds <torvalds@linux-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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
  2009-04-09 16:41 ` Kumar Gala
@ 2009-04-09 19:49   ` Sukadev Bhattiprolu
  2009-04-09 20:28     ` Kumar Gala
  0 siblings, 1 reply; 9+ messages in thread
From: Sukadev Bhattiprolu @ 2009-04-09 19:49 UTC (permalink / raw)
  To: Kumar Gala; +Cc: oleg, linux-kernel Mailing List, Andrew Morton

Kumar Gala [galak@kernel.crashing.org] wrote:
>
> 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 

Will try to repro on a normal machine, but can you attach the /proc/pid/status
(and possibly the stack) of the parent of the 'recv01' ?

If the parent is 'init', is there anything special about the init on your board
or on the simulator - like are you running the tests in a container ?

Sukadev

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
  2009-04-09 19:49   ` Sukadev Bhattiprolu
@ 2009-04-09 20:28     ` Kumar Gala
  2009-04-09 21:39       ` Sukadev Bhattiprolu
  0 siblings, 1 reply; 9+ messages in thread
From: Kumar Gala @ 2009-04-09 20:28 UTC (permalink / raw)
  To: Sukadev Bhattiprolu; +Cc: oleg, linux-kernel Mailing List, Andrew Morton


On Apr 9, 2009, at 2:49 PM, Sukadev Bhattiprolu wrote:

> Kumar Gala [galak@kernel.crashing.org] wrote:
>>
>> 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
>
> Will try to repro on a normal machine, but can you attach the /proc/ 
> pid/status
> (and possibly the stack) of the parent of the 'recv01' ?

Name:   recv01
State:  Z (zombie)
Tgid:   2449
Pid:    2449
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 0
Groups: 0 1 2 3 4 6 10
Threads:        1
SigQ:   8/16384
SigPnd: 0000000000000000
ShdPnd: 0000000000004100
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: fffffffffffffeff
CapEff: fffffffffffffeff
CapBnd: fffffffffffffeff
voluntary_ctxt_switches:        6
nonvoluntary_ctxt_switches:     0

If you have suggestion on how to dump the stack I can provide that as  
well.

> If the parent is 'init', is there anything special about the init on  
> your board
> or on the simulator - like are you running the tests in a container ?

Its an old init from fedora 3 or something like that.  Its not running  
in any special way (not container, no hypervisor, etc.)

- k

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
  2009-04-09 20:28     ` Kumar Gala
@ 2009-04-09 21:39       ` Sukadev Bhattiprolu
  2009-04-10  0:01         ` Kumar Gala
  0 siblings, 1 reply; 9+ messages in thread
From: Sukadev Bhattiprolu @ 2009-04-09 21:39 UTC (permalink / raw)
  To: Kumar Gala; +Cc: oleg, linux-kernel Mailing List, Andrew Morton

Kumar Gala [galak@kernel.crashing.org] wrote:
>
> On Apr 9, 2009, at 2:49 PM, Sukadev Bhattiprolu wrote:
>
>> Kumar Gala [galak@kernel.crashing.org] wrote:
>>>
>>> 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
>>
>> Will try to repro on a normal machine, but can you attach the 
>> /proc/pid/status
>> (and possibly the stack) of the parent of the 'recv01' ?
>
> Name:   recv01
> State:  Z (zombie)
> Tgid:   2449
> Pid:    2449
> PPid:   1

Ok, but I meant the status of the parent (i.e /proc/1/status in this case).

To get the stack, if CONFIG_MAGIC_SYSRQ=y, you can:

	$ echo 1 > /proc/sys/kernel/sysrq
	$ echo t > /proc/sysrq-trigger
	$ dmesg > /tmp/dmesg.out

Look in /tmp/dmesg.out for the process stack

Suka

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
  2009-04-09 21:39       ` Sukadev Bhattiprolu
@ 2009-04-10  0:01         ` Kumar Gala
  2009-04-10  1:03           ` Sukadev Bhattiprolu
  0 siblings, 1 reply; 9+ messages in thread
From: Kumar Gala @ 2009-04-10  0:01 UTC (permalink / raw)
  To: Sukadev Bhattiprolu; +Cc: oleg, linux-kernel Mailing List, Andrew Morton


On Apr 9, 2009, at 4:39 PM, Sukadev Bhattiprolu wrote:

> Kumar Gala [galak@kernel.crashing.org] wrote:
>>
>> On Apr 9, 2009, at 2:49 PM, Sukadev Bhattiprolu wrote:
>>
>>> Kumar Gala [galak@kernel.crashing.org] wrote:
>>>>
>>>> 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
>>>
>>> Will try to repro on a normal machine, but can you attach the
>>> /proc/pid/status
>>> (and possibly the stack) of the parent of the 'recv01' ?
>>
>> Name:   recv01
>> State:  Z (zombie)
>> Tgid:   2449
>> Pid:    2449
>> PPid:   1
>
> Ok, but I meant the status of the parent (i.e /proc/1/status in this  
> case).
>
> To get the stack, if CONFIG_MAGIC_SYSRQ=y, you can:
>
> 	$ echo 1 > /proc/sys/kernel/sysrq
> 	$ echo t > /proc/sysrq-trigger
> 	$ dmesg > /tmp/dmesg.out
>
> Look in /tmp/dmesg.out for the process stack
>
> Suka

-bash-3.2# ps
  PID TTY          TIME CMD
2289 ttyS0    00:00:00 bash
2310 ttyS0    00:00:00 runltp
2412 ttyS0    00:00:00 pan
2448 ttyS0    00:00:00 recv01 <defunct>
2450 ttyS0    00:00:00 recvfrom01 <defunct>
2452 ttyS0    00:00:00 recvmsg01 <defunct>
2473 ttyS0    00:00:00 rename14
2474 ttyS0    00:00:01 rename14
2477 ttyS0    00:00:00 rename14
2481 ttyS0    00:00:00 ps
-bash-3.2# cat /proc/1/status
Name:   init
State:  T (stopped)
Tgid:   1
Pid:    1
PPid:   0
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 32
Groups:
VmPeak:     1948 kB
VmSize:     1944 kB
VmLck:         0 kB
VmHWM:       648 kB
VmRSS:       648 kB
VmData:      164 kB
VmStk:        84 kB
VmExe:       288 kB
VmLib:      1124 kB
VmPTE:        20 kB
Threads:        1
SigQ:   8/16384
SigPnd: 0000000000000000
ShdPnd: 0000000000010000
SigBlk: 0000000000000000
SigIgn: fffffffe57f0d8fc
SigCgt: 00000000280b2603
CapInh: 0000000000000000
CapPrm: fffffffffffffeff
CapEff: fffffffffffffeff
CapBnd: fffffffffffffeff
voluntary_ctxt_switches:        87
nonvoluntary_ctxt_switches:     8
-bash-3.2# cat /proc/2448/stat
2448 (recv01) Z 1 2447 2289 1088 2483 4195404 45 0 0 0 0 0 0 0 20 0 1  
0 685 0 0
4294967295 0 0 0 0 0 0 0 0 0 3221418948 0 0 17 0 0 0 0 0 0
-bash-3.2# cat /proc/2448/status
Name:   recv01
State:  Z (zombie)
Tgid:   2448
Pid:    2448
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 0
Groups: 0 1 2 3 4 6 10
Threads:        1
SigQ:   8/16384
SigPnd: 0000000000000000
ShdPnd: 0000000000004100
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: fffffffffffffeff
CapEff: fffffffffffffeff
CapBnd: fffffffffffffeff
voluntary_ctxt_switches:        6
nonvoluntary_ctxt_switches:     0

--

-bash-3.2# echo t > /proc/sysrq-trigger
SysRq : Show State
Call Trace:
[ef82bc90] [00000900] 0x900 (unreliable)
[ef82bd50] [c0009570] __switch_to+0x8c/0xd4
[ef82bd70] [c0396f34] __schedule+0x2bc/0x7b4
[ef82bdf0] [c0397448] schedule+0x1c/0x3c
[ef82be00] [c003bce4] do_signal_stop+0xa0/0x16c
[ef82be20] [c003c7c0] get_signal_to_deliver+0x14c/0x3a4
[ef82be70] [c0009f0c] do_signal+0x88/0x284
[ef82bf40] [c0013838] do_user_signal+0x74/0xc4
--- Exception: c00 at 0xff39348
    LR = 0x10004cf8
Call Trace:
[ef831e30] [00001032] 0x1032 (unreliable)
[ef831ef0] [c0009570] __switch_to+0x8c/0xd4
[ef831f10] [c0396f34] __schedule+0x2bc/0x7b4
[ef831f90] [c0397448] schedule+0x1c/0x3c
[ef831fa0] [c0044b54] kthreadd+0x17c/0x18c
[ef831ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef833eb0] [c0009570] __switch_to+0x8c/0xd4
[ef833ed0] [c0396f34] __schedule+0x2bc/0x7b4
[ef833f50] [c0397448] schedule+0x1c/0x3c
[ef833f60] [c0028278] migration_thread+0x2bc/0x420
[ef833fd0] [c0044bb4] kthread+0x50/0x88
[ef833ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef839e30] [c019d110] blk_run_queue+0x28/0x48 (unreliable)
[ef839ef0] [c0009570] __switch_to+0x8c/0xd4
[ef839f10] [c0396f34] __schedule+0x2bc/0x7b4
[ef839f90] [c0397448] schedule+0x1c/0x3c
[ef839fa0] [c00317b0] ksoftirqd+0x108/0x158
[ef839fd0] [c0044bb4] kthread+0x50/0x88
[ef839ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef83bf00] [c0009570] __switch_to+0x8c/0xd4
[ef83bf20] [c0396f34] __schedule+0x2bc/0x7b4
[ef83bfa0] [c0397448] schedule+0x1c/0x3c
[ef83bfb0] [c0062eec] watchdog+0x48/0x88
[ef83bfd0] [c0044bb4] kthread+0x50/0x88
[ef83bff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef841ec0] [c0009570] __switch_to+0x8c/0xd4
[ef841ee0] [c0396f34] __schedule+0x2bc/0x7b4
[ef841f60] [c0397448] schedule+0x1c/0x3c
[ef841f70] [c004048c] worker_thread+0x1b4/0x1b8
[ef841fd0] [c0044bb4] kthread+0x50/0x88
[ef841ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef843ec0] [c0009570] __switch_to+0x8c/0xd4
[ef843ee0] [c0396f34] __schedule+0x2bc/0x7b4
[ef843f60] [c0397448] schedule+0x1c/0x3c
[ef843f70] [c004048c] worker_thread+0x1b4/0x1b8
[ef843fd0] [c0044bb4] kthread+0x50/0x88
[ef843ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef845e00] [c0022f4c] wake_up_new_task+0xb8/0x124 (unreliable)
[ef845ec0] [c0009570] __switch_to+0x8c/0xd4
[ef845ee0] [c0396f34] __schedule+0x2bc/0x7b4
[ef845f60] [c0397448] schedule+0x1c/0x3c
[ef845f70] [c004048c] worker_thread+0x1b4/0x1b8
[ef845fd0] [c0044bb4] kthread+0x50/0x88
[ef845ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef853ed0] [c0009570] __switch_to+0x8c/0xd4
[ef853ef0] [c0396f34] __schedule+0x2bc/0x7b4
[ef853f70] [c0397448] schedule+0x1c/0x3c
[ef853f80] [c004c5b0] async_manager_thread+0xfc/0x12c
[ef853fd0] [c0044bb4] kthread+0x50/0x88
[ef853ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef873ec0] [c0009570] __switch_to+0x8c/0xd4
[ef873ee0] [c0396f34] __schedule+0x2bc/0x7b4
[ef873f60] [c0397448] schedule+0x1c/0x3c
[ef873f70] [c004048c] worker_thread+0x1b4/0x1b8
[ef873fd0] [c0044bb4] kthread+0x50/0x88
[ef873ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef89de00] [00000001] 0x1 (unreliable)
[ef89dec0] [c0009570] __switch_to+0x8c/0xd4
[ef89dee0] [c0396f34] __schedule+0x2bc/0x7b4
[ef89df60] [c0397448] schedule+0x1c/0x3c
[ef89df70] [c004048c] worker_thread+0x1b4/0x1b8
[ef89dfd0] [c0044bb4] kthread+0x50/0x88
[ef89dff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef89fec0] [c0009570] __switch_to+0x8c/0xd4
[ef89fee0] [c0396f34] __schedule+0x2bc/0x7b4
[ef89ff60] [c0397448] schedule+0x1c/0x3c
[ef89ff70] [c004048c] worker_thread+0x1b4/0x1b8
[ef89ffd0] [c0044bb4] kthread+0x50/0x88
[ef89fff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef8a7e80] [c0009570] __switch_to+0x8c/0xd4
[ef8a7ea0] [c0396f34] __schedule+0x2bc/0x7b4
[ef8a7f20] [c0397448] schedule+0x1c/0x3c
[ef8a7f30] [c024d4e8] hub_thread+0xdb0/0xe98
[ef8a7fd0] [c0044bb4] kthread+0x50/0x88
[ef8a7ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef8a9eb0] [c0009570] __switch_to+0x8c/0xd4
[ef8a9ed0] [c0396f34] __schedule+0x2bc/0x7b4
[ef8a9f50] [c0397448] schedule+0x1c/0x3c
[ef8a9f60] [c0270574] serio_thread+0x304/0x35c
[ef8a9fd0] [c0044bb4] kthread+0x50/0x88
[ef8a9ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef851de0] [c00672dc] call_rcu+0x50/0x68 (unreliable)
[ef851ea0] [c0009570] __switch_to+0x8c/0xd4
[ef851ec0] [c0396f34] __schedule+0x2bc/0x7b4
[ef851f40] [c0397448] schedule+0x1c/0x3c
[ef851f50] [c0397714] schedule_timeout+0x12c/0x1a4
[ef851f90] [c0063224] watchdog+0x60/0x208
[ef851fd0] [c0044bb4] kthread+0x50/0x88
[ef851ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef8abdf0] [ef4032b4] 0xef4032b4 (unreliable)
[ef8abeb0] [c0009570] __switch_to+0x8c/0xd4
[ef8abed0] [c0396f34] __schedule+0x2bc/0x7b4
[ef8abf50] [c0397448] schedule+0x1c/0x3c
[ef8abf60] [c0072554] pdflush+0x100/0x254
[ef8abfd0] [c0044bb4] kthread+0x50/0x88
[ef8abff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef8adeb0] [c0009570] __switch_to+0x8c/0xd4
[ef8aded0] [c0396f34] __schedule+0x2bc/0x7b4
[ef8adf50] [c0397448] schedule+0x1c/0x3c
[ef8adf60] [c0072554] pdflush+0x100/0x254
[ef8adfd0] [c0044bb4] kthread+0x50/0x88
[ef8adff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef8afe60] [c0009570] __switch_to+0x8c/0xd4
[ef8afe80] [c0396f34] __schedule+0x2bc/0x7b4
[ef8aff00] [c0397448] schedule+0x1c/0x3c
[ef8aff10] [c00778d0] kswapd+0x5c8/0x5d0
[ef8affd0] [c0044bb4] kthread+0x50/0x88
[ef8afff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[efab9ec0] [c0009570] __switch_to+0x8c/0xd4
[efab9ee0] [c0396f34] __schedule+0x2bc/0x7b4
[efab9f60] [c0397448] schedule+0x1c/0x3c
[efab9f70] [c004048c] worker_thread+0x1b4/0x1b8
[efab9fd0] [c0044bb4] kthread+0x50/0x88
[efab9ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[efabbec0] [c0009570] __switch_to+0x8c/0xd4
[efabbee0] [c0396f34] __schedule+0x2bc/0x7b4
[efabbf60] [c0397448] schedule+0x1c/0x3c
[efabbf70] [c004048c] worker_thread+0x1b4/0x1b8
[efabbfd0] [c0044bb4] kthread+0x50/0x88
[efabbff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[efac7ec0] [c0009570] __switch_to+0x8c/0xd4
[efac7ee0] [c0396f34] __schedule+0x2bc/0x7b4
[efac7f60] [c0397448] schedule+0x1c/0x3c
[efac7f70] [c004048c] worker_thread+0x1b4/0x1b8
[efac7fd0] [c0044bb4] kthread+0x50/0x88
[efac7ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[efb89e00] [72626f20] 0x72626f20 (unreliable)
[efb89ec0] [c0009570] __switch_to+0x8c/0xd4
[efb89ee0] [c0396f34] __schedule+0x2bc/0x7b4
[efb89f60] [c0397448] schedule+0x1c/0x3c
[efb89f70] [c0205a24] scsi_error_handler+0xa4/0x5f8
[efb89fd0] [c0044bb4] kthread+0x50/0x88
[efb89ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[eedd9e00] [eedd9e18] 0xeedd9e18 (unreliable)
[eedd9ec0] [c0009570] __switch_to+0x8c/0xd4
[eedd9ee0] [c0396f34] __schedule+0x2bc/0x7b4
[eedd9f60] [c0397448] schedule+0x1c/0x3c
[eedd9f70] [c0205a24] scsi_error_handler+0xa4/0x5f8
[eedd9fd0] [c0044bb4] kthread+0x50/0x88
[eedd9ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[eee23e00] [c1808880] 0xc1808880 (unreliable)
[eee23ec0] [c0009570] __switch_to+0x8c/0xd4
[eee23ee0] [c0396f34] __schedule+0x2bc/0x7b4
[eee23f60] [c0397448] schedule+0x1c/0x3c
[eee23f70] [c004048c] worker_thread+0x1b4/0x1b8
[eee23fd0] [c0044bb4] kthread+0x50/0x88
[eee23ff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[ef2bbe00] [ef2ba000] 0xef2ba000 (unreliable)
[ef2bbec0] [c0009570] __switch_to+0x8c/0xd4
[ef2bbee0] [c0396f34] __schedule+0x2bc/0x7b4
[ef2bbf60] [c0397448] schedule+0x1c/0x3c
[ef2bbf70] [c004048c] worker_thread+0x1b4/0x1b8
[ef2bbfd0] [c0044bb4] kthread+0x50/0x88
[ef2bbff0] [c0012e5c] kernel_thread+0x4c/0x68
Call Trace:
[eee0b980] [c0009570] __switch_to+0x8c/0xd4
[eee0b9a0] [c0396f34] __schedule+0x2bc/0x7b4
[eee0ba20] [c0397448] schedule+0x1c/0x3c
[eee0ba30] [c03986f0] schedule_hrtimeout_range+0x1ac/0x1b8
[eee0bab0] [c00acf88] poll_schedule_timeout+0x3c/0x60
[eee0bac0] [c00adc34] do_select+0x3ec/0x4b0
[eee0bdb0] [c00adf8c] core_sys_select+0x294/0x388
[eee0bf00] [c00ae364] sys_select+0x40/0x138
[eee0bf30] [c00055f0] ppc_select+0x18/0xa0
[eee0bf40] [c0013038] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x200b6348
    LR = 0x20183c50
Call Trace:
[ee831cf0] [c02c0ecc] sock_alloc_send_pskb+0x208/0x31c (unreliable)
[ee831db0] [c0009570] __switch_to+0x8c/0xd4
[ee831dd0] [c0396f34] __schedule+0x2bc/0x7b4
[ee831e50] [c0397448] schedule+0x1c/0x3c
[ee831e60] [c002cd68] do_syslog+0x444/0x49c
[ee831ec0] [c00eaf08] kmsg_read+0x34/0x68
[ee831ed0] [c00e0fc8] proc_reg_read+0x80/0xb4
[ee831ef0] [c009d16c] vfs_read+0xb4/0x16c
[ee831f10] [c009d32c] sys_read+0x4c/0xa4
[ee831f40] [c0013038] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x2055b0dc
    LR = 0x2062c178
Call Trace:
[ef2a5980] [c0009570] __switch_to+0x8c/0xd4
[ef2a59a0] [c0396f34] __schedule+0x2bc/0x7b4
[ef2a5a20] [c0397448] schedule+0x1c/0x3c
[ef2a5a30] [c03986f0] schedule_hrtimeout_range+0x1ac/0x1b8
[ef2a5ab0] [c00acf88] poll_schedule_timeout+0x3c/0x60
[ef2a5ac0] [c00adc34] do_select+0x3ec/0x4b0
[ef2a5db0] [c00adf8c] core_sys_select+0x294/0x388
[ef2a5f00] [c00ae364] sys_select+0x40/0x138
[ef2a5f30] [c00055f0] ppc_select+0x18/0xa0
[ef2a5f40] [c0013038] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x2047c348
    LR = 0x2078456c
Call Trace:
[efac9d30] [c006be0c] mempool_free+0xb8/0xcc (unreliable)
[efac9df0] [c0009570] __switch_to+0x8c/0xd4
[efac9e10] [c0396f34] __schedule+0x2bc/0x7b4
[efac9e90] [c0397448] schedule+0x1c/0x3c
[efac9ea0] [c002ec3c] do_wait+0x210/0x3c4
[efac9f20] [c002ee6c] sys_wait4+0x7c/0xc4
[efac9f40] [c0013038] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfde21e8
    LR = 0xfec28a8
Call Trace:
[ee827e20] [c0008c34] show_stack+0x48/0x15c (unreliable)
[ee827e50] [c0026e10] sched_show_task+0xbc/0xf8
[ee827e60] [c0026ec4] show_state_filter+0x78/0xdc
[ee827e80] [c01e883c] sysrq_handle_showstate+0x14/0x24
[ee827e90] [c01e8684] __handle_sysrq+0xd0/0x1c0
[ee827ec0] [c01e87d0] write_sysrq_trigger+0x5c/0x68
[ee827ed0] [c00e0f14] proc_reg_write+0x80/0xb4
[ee827ef0] [c009cea0] vfs_write+0xb4/0x16c
[ee827f10] [c009d060] sys_write+0x4c/0xa4
[ee827f40] [c0013038] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfe89160
    LR = 0xfe373b4
Call Trace:
[eeca7c90] [c052b9e8] __per_cpu_offset+0x0/0x8 (unreliable)
[eeca7d50] [c0009570] __switch_to+0x8c/0xd4
[eeca7d70] [c0396f34] __schedule+0x2bc/0x7b4
[eeca7df0] [c0397448] schedule+0x1c/0x3c
[eeca7e00] [c003bce4] do_signal_stop+0xa0/0x16c
[eeca7e20] [c003c7c0] get_signal_to_deliver+0x14c/0x3a4
[eeca7e70] [c0009f0c] do_signal+0x88/0x284
[eeca7f40] [c0013838] do_user_signal+0x74/0xc4
--- Exception: c00 at 0xfe64288
    LR = 0x10036560
Call Trace:
[ee821c90] [00000140] 0x140 (unreliable)
[ee821d50] [c0009570] __switch_to+0x8c/0xd4
[ee821d70] [c0396f34] __schedule+0x2bc/0x7b4
[ee821df0] [c0397448] schedule+0x1c/0x3c
[ee821e00] [c003bce4] do_signal_stop+0xa0/0x16c
[ee821e20] [c003c7c0] get_signal_to_deliver+0x14c/0x3a4
[ee821e70] [c0009f0c] do_signal+0x88/0x284
[ee821f40] [c0013838] do_user_signal+0x74/0xc4
--- Exception: c00 at 0xfe191e8
    LR = 0xfef98a8
Call Trace:
[efba1c40] [ee9ee000] 0xee9ee000 (unreliable)
[efba1d00] [c0009570] __switch_to+0x8c/0xd4
[efba1d20] [c0396f34] __schedule+0x2bc/0x7b4
[efba1da0] [c0397448] schedule+0x1c/0x3c
[efba1db0] [c002f3c4] do_exit+0x440/0x61c
[efba1e00] [c002f5e8] do_group_exit+0x48/0xb4
[efba1e20] [c003c824] get_signal_to_deliver+0x1b0/0x3a4
[efba1e70] [c0009f0c] do_signal+0x88/0x284
[efba1f40] [c0013838] do_user_signal+0x74/0xc4
--- Exception: c00 at 0xff39348
    LR = 0x10001b00
Call Trace:
[ee9e5c40] [ee9ee160] 0xee9ee160 (unreliable)
[ee9e5d00] [c0009570] __switch_to+0x8c/0xd4
[ee9e5d20] [c0396f34] __schedule+0x2bc/0x7b4
[ee9e5da0] [c0397448] schedule+0x1c/0x3c
[ee9e5db0] [c002f3c4] do_exit+0x440/0x61c
[ee9e5e00] [c002f5e8] do_group_exit+0x48/0xb4
[ee9e5e20] [c003c824] get_signal_to_deliver+0x1b0/0x3a4
[ee9e5e70] [c0009f0c] do_signal+0x88/0x284
[ee9e5f40] [c0013838] do_user_signal+0x74/0xc4
--- Exception: c00 at 0xff39348
    LR = 0x10001b94
Call Trace:
[eeddbc40] [c02ca018] __scm_destroy+0xdc/0x104 (unreliable)
[eeddbd00] [c0009570] __switch_to+0x8c/0xd4
[eeddbd20] [c0396f34] __schedule+0x2bc/0x7b4
[eeddbda0] [c0397448] schedule+0x1c/0x3c
[eeddbdb0] [c002f3c4] do_exit+0x440/0x61c
[eeddbe00] [c002f5e8] do_group_exit+0x48/0xb4
[eeddbe20] [c003c824] get_signal_to_deliver+0x1b0/0x3a4
[eeddbe70] [c0009f0c] do_signal+0x88/0x284
[eeddbf40] [c0013838] do_user_signal+0x74/0xc4
--- Exception: c00 at 0xff39348
    LR = 0x100024e4
Call Trace:
[efb95dc0] [eea50030] 0xeea50030 (unreliable)
[efb95e80] [c0009570] __switch_to+0x8c/0xd4
[efb95ea0] [c0396f34] __schedule+0x2bc/0x7b4
[efb95f20] [c0397448] schedule+0x1c/0x3c
[efb95f30] [c0038eac] sys_pause+0x18/0x2c
[efb95f40] [c0013038] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff0c9a8
    LR = 0x10000f3c
Call Trace:
[eee03dd0] [00000001] 0x1 (unreliable)
[eee03e90] [c0009570] __switch_to+0x8c/0xd4
[eee03eb0] [c0396f34] __schedule+0x2bc/0x7b4
[eee03f30] [c0397448] schedule+0x1c/0x3c
[eee03f40] [c00137a4] recheck+0x0/0x20
--- Exception: c01 at 0xff31068
    LR = 0x100011a0
Call Trace:
[eedd7dd0] [ef824000] 0xef824000 (unreliable)
[eedd7e90] [c0009570] __switch_to+0x8c/0xd4
[eedd7eb0] [c0396f34] __schedule+0x2bc/0x7b4
[eedd7f30] [c0397448] schedule+0x1c/0x3c
[eedd7f40] [c00137a4] recheck+0x0/0x20
--- Exception: c01 at 0xfecfcbc
    LR = 0x100011cc
Sched Debug Version: v0.09, 2.6.30-rc1 #17
now at 11328.667077 msecs
  .jiffies                                 : 4294678606
  .sysctl_sched_latency                    : 20.000000
  .sysctl_sched_min_granularity            : 4.000000
  .sysctl_sched_wakeup_granularity         : 5.000000
  .sysctl_sched_child_runs_first           : 0.000001
  .sysctl_sched_features                   : 113917

cpu#0
  .nr_running                    : 3
  .load                          : 3072
  .nr_switches                   : 11083
  .nr_load_updates               : 6686
  .nr_uninterruptible            : 0
  .next_balance                  : 4294.674587
  .curr->pid                     : 2289
  .clock                         : 11311.326992
  .cpu_load[0]                   : 2048
  .cpu_load[1]                   : 2048
  .cpu_load[2]                   : 2048
  .cpu_load[3]                   : 2048
  .cpu_load[4]                   : 2048

cfs_rq[0]:
  .exec_clock                    : 0.000000
  .MIN_vruntime                  : 6826.174825
  .min_vruntime                  : 6826.172137
  .max_vruntime                  : 6826.606277
  .spread                        : 0.431452
  .spread0                       : 0.000000
  .nr_running                    : 3
  .load                          : 3072
  .nr_spread_over                : 0

rt_rq[0]:
  .rt_nr_running                 : 0
  .rt_throttled                  : 0
  .rt_time                       : 0.000000
  .rt_runtime                    : 950.000000

runnable tasks:
            task   PID         tree-key  switches  prio     exec-runtime
sum-exec        sum-sleep
--------------------------------------------------------------------------------
--------------------------
R           bash  2289      6806.177849       350   120               0
      0               0.000000               0.000000                
0.000000
        rename14  2474      6826.174825       265   120               0
      0               0.000000               0.000000                
0.000000
        rename14  2477      6826.606277       322   120               0
      0               0.000000               0.000000                
0.000000


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
  2009-04-10  0:01         ` Kumar Gala
@ 2009-04-10  1:03           ` Sukadev Bhattiprolu
  2009-04-10  5:24             ` Kumar Gala
  0 siblings, 1 reply; 9+ messages in thread
From: Sukadev Bhattiprolu @ 2009-04-10  1:03 UTC (permalink / raw)
  To: Kumar Gala; +Cc: oleg, linux-kernel Mailing List, Andrew Morton

>
> -bash-3.2# ps
>  PID TTY          TIME CMD
> 2289 ttyS0    00:00:00 bash
> 2310 ttyS0    00:00:00 runltp
> 2412 ttyS0    00:00:00 pan
> 2448 ttyS0    00:00:00 recv01 <defunct>
> 2450 ttyS0    00:00:00 recvfrom01 <defunct>
> 2452 ttyS0    00:00:00 recvmsg01 <defunct>
> 2473 ttyS0    00:00:00 rename14
> 2474 ttyS0    00:00:01 rename14
> 2477 ttyS0    00:00:00 rename14
> 2481 ttyS0    00:00:00 ps
> -bash-3.2# cat /proc/1/status
> Name:   init
> State:  T (stopped)

init is in the stopped state.  Can you run "kill -CONT 1" ?

> Tgid:   1
> Pid:    1
> PPid:   0
> TracerPid:      0
> Uid:    0       0       0       0
> Gid:    0       0       0       0
> FDSize: 32
> Groups:
> VmPeak:     1948 kB
> VmSize:     1944 kB
> VmLck:         0 kB
> VmHWM:       648 kB
> VmRSS:       648 kB
> VmData:      164 kB
> VmStk:        84 kB
> VmExe:       288 kB
> VmLib:      1124 kB
> VmPTE:        20 kB
> Threads:        1
> SigQ:   8/16384
> SigPnd: 0000000000000000
> ShdPnd: 0000000000010000

Init does have the pending SIGCHLD, so the zombies should go away 
when init gets the SIGCONT.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
  2009-04-10  1:03           ` Sukadev Bhattiprolu
@ 2009-04-10  5:24             ` Kumar Gala
  2009-04-10 12:15               ` Oleg Nesterov
  0 siblings, 1 reply; 9+ messages in thread
From: Kumar Gala @ 2009-04-10  5:24 UTC (permalink / raw)
  To: Sukadev Bhattiprolu; +Cc: oleg, linux-kernel Mailing List, Andrew Morton


On Apr 9, 2009, at 8:03 PM, Sukadev Bhattiprolu wrote:

>>
>> -bash-3.2# ps
>> PID TTY          TIME CMD
>> 2289 ttyS0    00:00:00 bash
>> 2310 ttyS0    00:00:00 runltp
>> 2412 ttyS0    00:00:00 pan
>> 2448 ttyS0    00:00:00 recv01 <defunct>
>> 2450 ttyS0    00:00:00 recvfrom01 <defunct>
>> 2452 ttyS0    00:00:00 recvmsg01 <defunct>
>> 2473 ttyS0    00:00:00 rename14
>> 2474 ttyS0    00:00:01 rename14
>> 2477 ttyS0    00:00:00 rename14
>> 2481 ttyS0    00:00:00 ps
>> -bash-3.2# cat /proc/1/status
>> Name:   init
>> State:  T (stopped)
>
> init is in the stopped state.  Can you run "kill -CONT 1" ?

yes

>> Tgid:   1
>> Pid:    1
>> PPid:   0
>> TracerPid:      0
>> Uid:    0       0       0       0
>> Gid:    0       0       0       0
>> FDSize: 32
>> Groups:
>> VmPeak:     1948 kB
>> VmSize:     1944 kB
>> VmLck:         0 kB
>> VmHWM:       648 kB
>> VmRSS:       648 kB
>> VmData:      164 kB
>> VmStk:        84 kB
>> VmExe:       288 kB
>> VmLib:      1124 kB
>> VmPTE:        20 kB
>> Threads:        1
>> SigQ:   8/16384
>> SigPnd: 0000000000000000
>> ShdPnd: 0000000000010000
>
> Init does have the pending SIGCHLD, so the zombies should go away
> when init gets the SIGCONT.

That seems to clear it up.. But why has the behavior changed?  I  
didn't have to do the "kill -CONT 1" on 2.6.29.

- k

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?)
  2009-04-10  5:24             ` Kumar Gala
@ 2009-04-10 12:15               ` Oleg Nesterov
  0 siblings, 0 replies; 9+ messages in thread
From: Oleg Nesterov @ 2009-04-10 12:15 UTC (permalink / raw)
  To: Kumar Gala; +Cc: Sukadev Bhattiprolu, linux-kernel Mailing List, Andrew Morton

On 04/10, Kumar Gala wrote:
>
> That seems to clear it up.. But why has the behavior changed?  I didn't
> have to do the "kill -CONT 1" on 2.6.29.

I didn't look at the test-case yet, so I don't know what happens.

But, before this comment, /sbin/init always ignored SIGSTOP.
Now it is possible to stop init. Of course, user-space can't
send SIGSTOP to init directly. But if you are ptracer, or send
SIGSTOP to the sub-namespace, it should work.

Oleg.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2009-04-10 12:22 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-09 15:43 LTP 20080131 causes defunct processes w/2.6.30-rc1 (possible ptrace issue?) Kumar Gala
2009-04-09 16:41 ` Kumar Gala
2009-04-09 19:49   ` Sukadev Bhattiprolu
2009-04-09 20:28     ` Kumar Gala
2009-04-09 21:39       ` Sukadev Bhattiprolu
2009-04-10  0:01         ` Kumar Gala
2009-04-10  1:03           ` Sukadev Bhattiprolu
2009-04-10  5:24             ` Kumar Gala
2009-04-10 12:15               ` Oleg Nesterov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox