View Issue Details

IDProjectCategoryView StatusLast Update
0005424CentOS-6kernelpublic2013-02-27 01:13
Reporterrex 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version6.2 
Target VersionFixed in Version 
Summary0005424: ptrace() does not work correctly with PID namespaces
DescriptionGDB tells "warning: linux_test_for_tracefork: failed to kill second child" when used in a PID namespace and leaves a stopped child on exit.
Steps To Reproduce1. Start PID namespace.
2. In this new namespace, use GDB with a program.
Additional InformationSome example display output:

# ./ns_exec
# gdb ./test
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6)
[...]
(gdb) start
[...]
warning: linux_test_for_tracefork: failed to kill second child
[...]
(gdb) quit
A debugging session is active.

        Inferior 1 [process 34] will be killed.

Quit anyway? (y or n) y
[root@n0010 ~]# ps ux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 16512 312 pts/1 Sl+ 10:22 0:00 /root/ns_exec
[...]
root 36 0.0 0.0 164700 3720 pts/2 T 10:22 0:00 gdb ./test
TagsNo tags attached.

Activities

rex

rex

2012-01-16 10:56

reporter  

possible_kernel_patch.diff (582 bytes)
diff -Nurp old/linux-2.6.32-220.el6/kernel/ptrace-utrace.c new/linux-2.6.32-220.el6/kernel/ptrace-utrace.c
--- old/linux-2.6.32-220.el6/kernel/ptrace-utrace.c	2011-11-08 22:05:04.000000000 +0100
+++ new/linux-2.6.32-220.el6/kernel/ptrace-utrace.c	2012-01-16 10:36:54.000000000 +0100
@@ -403,7 +403,7 @@ static u32 ptrace_report_clone(u32 actio
 		return UTRACE_RESUME;
 
 	set_stop_code(ctx, event);
-	ctx->eventmsg = child->pid;
+	ctx->eventmsg = task_pid_vnr(child);
 	/*
 	 * We shouldn't stop now, inside the do_fork() path.
 	 * We will stop later, before return to user-mode.
rex

rex

2012-01-16 10:57

reporter  

ns_exec.c (1,430 bytes)
toracat

toracat

2012-01-16 14:40

manager   ~0014208

Is the patch in the upstream (kernel.org) kernel? Or is this something new, and if so, are you planning to sumbit it?
rex

rex

2012-01-16 15:05

reporter   ~0014209

No, the patch is not in the Vanilla kernel (they reworked the whole ptrace code as far as I looked at it and I found no similar source code; but I didn't try this test case with some of their kernels yet).
So this seems to be something new. I did not take any further actions (except of testing the patch on my local system), because I don't know where/how to submit that patch.

Thanks for your help!
toracat

toracat

2012-01-16 16:25

manager   ~0014212

Thanks for the note.

As you may know, CentOS cannot modify the distro kernel. So, you really need to submit the patch to RH. On the other hand, it is entirely possible to apply the patch to the centosplus kernel. Would you like to see your patch incorporated into this custom kernel?
rex

rex

2012-01-17 12:05

reporter   ~0014226

Thanks for your explanation! I filed a bug at the RH bugtracker now (see https://bugzilla.redhat.com/show_bug.cgi?id=782330).
Thus, it may not be necessary to apply it to the centosplus kernel, right?
toracat

toracat

2012-01-17 21:12

manager   ~0014233

Once the patch is in the RH kernel, CentOS will inherit it. But it usually takes a long time for them to incorporate any new patch. This is especially true when the patch is not in the 'stable' version of the kernel from kernel.org.

The centosplus kernel is a custom kernel. Config may be modified and patches can be applied. If requested, we will consider adding your patch to the next kernel update.
rex

rex

2012-01-18 16:47

reporter   ~0014259

Currently, it's not an urgent issue for me, so I think I can wait the time necessary for the patch to be applied to the distro kernel.
toracat

toracat

2012-01-18 16:57

manager   ~0014261

Alright. Please post any new development here.
toracat

toracat

2012-07-25 15:54

manager   ~0015540

@rex

It looks as if there will be no further action from upstream (BZ 782330). What would you like to do? Getting the patch applied to the centosplus kernel or waiting longer?
rex

rex

2012-07-26 06:17

reporter   ~0015551

Thanks for your note! I think it would be nice to get this patch applied to the centosplus kernel. We use the PID namespace feature permanently, so this issue still remains.
toracat

toracat

2012-07-26 10:52

manager   ~0015552

Last edited: 2012-07-26 10:56

View 2 revisions

OK. The original patch that appeared in Fedora 14 was:

https://bugzilla.redhat.com/show_bug.cgi?id=573210

ptrace_report_clone() uses child->pid, this is obviously wrong unless
the tracer is from the global namespace. Change it to use task_pid_vnr().

This is still not right, we should use the tracer's namespace, not
parent's. But this matches upstream, and at least this works if they
are from the same namespace.

Reported-by: Robin Green <greenrd at greenrd.org>
Signed-off-by: Oleg Nesterov <oleg at redhat.com>

--- a/kernel/ptrace-utrace.c
+++ b/kernel/ptrace-utrace.c
@@ -403,7 +403,7 @@ static u32 ptrace_report_clone(u32 actio
         return UTRACE_RESUME;
 
     set_stop_code(ctx, event);
- ctx->eventmsg = child->pid;
+ ctx->eventmsg = task_pid_vnr(child);
     /*
      * We shouldn't stop now, inside the do_fork() path.
      * We will stop later, before return to user-mode.

[EDIT] ref: http://lists.fedoraproject.org/pipermail/kernel/2011-August/003340.html

toracat

toracat

2012-07-26 17:19

manager   ~0015555

@rex

Can you try the test plus kernel that has the referenced patch applied? You can download it from:

http://people.centos.org/toracat/kernel/6/plus/2.6.32-279.2.1.bug5859bug5424.el6.centos.plus/

Please note that the packages in there are not signed. Once confirmed, the patch will be included in the next release of cplus kernels.
rex

rex

2012-07-27 06:26

reporter   ~0015559

Looks good. Everything works as expected with this patched kernel!
toracat

toracat

2012-07-27 12:27

manager   ~0015560

Perfect. Thanks for reporting back.
toracat

toracat

2012-08-14 20:26

manager   ~0015652

kernel 2.6.32-279.5.1.el6 is out upstream. The patch is now included in this release of the plus kernel.
toracat

toracat

2013-02-20 16:37

manager   ~0016511

Looks like the patch will be in the upcoming EL 6.4 kernel.
toracat

toracat

2013-02-27 01:13

manager   ~0016546

The patch is in the 6.4 kernel ( 2.6.32-358.el6 ).

Issue History

Date Modified Username Field Change
2012-01-16 10:55 rex New Issue
2012-01-16 10:56 rex File Added: possible_kernel_patch.diff
2012-01-16 10:57 rex File Added: ns_exec.c
2012-01-16 14:40 toracat Note Added: 0014208
2012-01-16 15:05 rex Note Added: 0014209
2012-01-16 16:25 toracat Note Added: 0014212
2012-01-16 16:25 toracat Status new => acknowledged
2012-01-17 12:05 rex Note Added: 0014226
2012-01-17 21:12 toracat Note Added: 0014233
2012-01-18 16:47 rex Note Added: 0014259
2012-01-18 16:57 toracat Note Added: 0014261
2012-07-25 15:54 toracat Note Added: 0015540
2012-07-25 15:55 toracat Status acknowledged => feedback
2012-07-26 06:17 rex Note Added: 0015551
2012-07-26 06:17 rex Status feedback => assigned
2012-07-26 10:52 toracat Note Added: 0015552
2012-07-26 10:56 toracat Note Edited: 0015552 View Revisions
2012-07-26 17:19 toracat Note Added: 0015555
2012-07-26 17:20 toracat Status assigned => feedback
2012-07-27 06:26 rex Note Added: 0015559
2012-07-27 06:26 rex Status feedback => assigned
2012-07-27 12:27 toracat Note Added: 0015560
2012-08-14 20:26 toracat Note Added: 0015652
2013-02-20 16:37 toracat Note Added: 0016511
2013-02-27 01:13 toracat Note Added: 0016546
2013-02-27 01:13 toracat Status assigned => resolved
2013-02-27 01:13 toracat Resolution open => fixed