Bug 544138

Summary: PTRACE_KILL hangs in 100% cpu loop
Product: Red Hat Enterprise Linux 5 Reporter: Tom Horsley <horsley1953>
Component: kernelAssignee: Vitaly Mayatskikh <vmayatsk>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4CC: jarod, onestero, qcai, roland, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-30 07:46:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
kill-bug.c g++ test program none

Description Tom Horsley 2009-12-04 01:04:03 UTC 
Description of problem:

If you (perhaps foolishly) try to ptrace(PTRACE_KILL,kid,0,0) a debugged
process "kid" that is not stopped, the debugger process goes to 100%
cpu looping in the ptrace call and is unkillable (fortunately you can
kill the kid, at which point the parent will come out of the ptrace service)

Version-Release number of selected component (if applicable):
kernel-2.6.18-164.el5
(also happens on newer kernels like 2.6.18-164.6.1.el5)

How reproducible:
every time

Steps to Reproduce:
1. g++ -o kill-bug kill-bug.c
2. ./kill-bug
3. see hung process
  
Actual results:
Hung process

Expected results:
It would be nice if the ptrace call actually failed, but most version
of the linux kernel appear to simply return success even though they don't
make the slightest attempt to kill the running process.

Additional info:
I'll attach a test program (kill-bug.c) to reproduce the bug.
Comment 1 Tom Horsley 2009-12-04 01:04:45 UTC 
Created attachment 375970 [details]
kill-bug.c g++ test program
Comment 2 Oleg Nesterov 2009-12-15 17:08:30 UTC 
(In reply to comment #0)
>
> It would be nice if the ptrace call actually failed, but most version
> of the linux kernel appear to simply return success even though they don't
> make the slightest attempt to kill the running process.
 
this is ugly, but correct. PTRACE_SIGKILL does nothing if the
tracee is not stopped, this is historical behaviour. Well, it
has some "side effects", but they don't matter in this case.

If the tracee is stopped/traced, then PTRACE_SIGKILL is equivalent
to ptrace(PTRACE_CONT, SIGKILL).

But the tracer should not hang.
Comment 3 Oleg Nesterov 2009-12-15 17:33:01 UTC 
(In reply to comment #2)
> 
> But the tracer should not hang.

    while (!TASK_TRACED && !TASK_STOPPED) {
            wait_task_inactive()
    }

in ptrace_start(), I guess.
Comment 5 RHEL Program Management 2010-02-04 22:02:18 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 13 errata-xmlrpc 2010-03-30 07:46:46 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0178.html