Re: Testing lxc 0.6.5 in Fedora 13

From: Matt Helsley
Date: Tue Apr 06 2010 - 11:30:05 EST

On Tue, Apr 06, 2010 at 08:13:13AM -0700, Eric W. Biederman wrote:
> Matt Helsley <matthltc@xxxxxxxxxx> writes:
> > On Mon, Apr 05, 2010 at 08:44:43PM -0700, Roland McGrath wrote:


> >> None of this has much of anything to do with strace, of course. As I've
> >> said, I don't see anything other than the PTRACE_GETEVENTMSG value for
> >> PTRACE_EVENT_{CLONE,FORK,VFORK} reports that is wrong in the kernel. As
> >> Oleg said, strace doesn't use that at all. (This is not the place to
> >> discuss the details of strace further.)
> >
> > Also, looking at proposed changes (utrace and Eric Biederman's setns())
> > storing a pid nr rather than a reference to a task struct or struct pid
> > probably won't be correct.
> My setns work has demonstrated that even for entering a namespace we
> never ever need to change the struct pid of a task. setns has no other
> bearing on this problem then to say there is no foreseeable reason to
> change the rules.
> > In the case of Eric Biederman's setns(), if capable of changing pid namespace,
> > we could have:
> >
> > Traced Tracer
> > fork()
> > ... (an arbitrary amount of time passes)
> > setns()
> > ptrace(GETEVENTMSG)
> Forget that. The pid namespace was architected so that we can ptrace a process
> in another pid namespace.
> > At which point returning a static pid number held in the message field
> > produces the wrong pid.
> No. A processes always sees pids from the context of it's original pid
> namespace. All setns does is affect which pid namespace children will
> be native in.

OK, good. So we can resolve the tasks/struct pids within the tracehook
and be done with it. Thanks Eric!

-Matt Helsley
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at