On Tue, 29 Apr 2014 13:20:58 -0700 Matthew Dempsky
wrote:
> When tracing a process in another pid namespace, it's important for
> fork event messages to contain the child's pid as seen from the
> tracer's pid namespace, not the parent's. Otherwise, the tracer won't
> be able to correlate the
v4 resend:
- Ran "git pull --rebase"; no code changes needed.
v4:
- Refactor out ptrace_event_pid() to dedup FIXME code
- Handle task_active_pid_ns() returning NULL
- Use rcu_dereference() for accessing current->parent
v3:
- Respond to Oleg feedback about
v4 resend:
- Ran git pull --rebase; no code changes needed.
v4:
- Refactor out ptrace_event_pid() to dedup FIXME code
- Handle task_active_pid_ns() returning NULL
- Use rcu_dereference() for accessing current-parent
v3:
- Respond to Oleg feedback about p
On Tue, 29 Apr 2014 13:20:58 -0700 Matthew Dempsky mdemp...@chromium.org
wrote:
When tracing a process in another pid namespace, it's important for
fork event messages to contain the child's pid as seen from the
tracer's pid namespace, not the parent's. Otherwise, the tracer won't
be able
On 04/03, Matthew Dempsky wrote:
>
> On Thu, Apr 3, 2014 at 8:44 AM, Oleg Nesterov wrote:
>
> > Some notes for potential future changes...
> >
> > - I do not not see any potential user of ptrace_event_pid() outside
> > of fork.c, so perhaps this helper should not be exported.
>
On 04/03, Matthew Dempsky wrote:
On Thu, Apr 3, 2014 at 8:44 AM, Oleg Nesterov o...@redhat.com wrote:
Some notes for potential future changes...
- I do not not see any potential user of ptrace_event_pid() outside
of fork.c, so perhaps this helper should not be
On Thu, Apr 3, 2014 at 8:44 AM, Oleg Nesterov wrote:
> On 04/02, Matthew Dempsky wrote:
>>
>> When tracing a process in another pid namespace, it's important for
>> fork event messages to contain the child's pid as seen from the
>> tracer's pid namespace, not the parent's. Otherwise, the tracer
On 04/03, Oleg Nesterov wrote:
>
> Some notes for potential future changes...
>
> - I do not not see any potential user of ptrace_event_pid() outside
> of fork.c, so perhaps this helper should not be exported.
>
> In fact I wouldn't mind if you send v5 which moves it into
On 04/02, Matthew Dempsky wrote:
>
> When tracing a process in another pid namespace, it's important for
> fork event messages to contain the child's pid as seen from the
> tracer's pid namespace, not the parent's. Otherwise, the tracer won't
> be able to correlate the fork event with later
On 04/02, Matthew Dempsky wrote:
When tracing a process in another pid namespace, it's important for
fork event messages to contain the child's pid as seen from the
tracer's pid namespace, not the parent's. Otherwise, the tracer won't
be able to correlate the fork event with later SIGTRAP
On 04/03, Oleg Nesterov wrote:
Some notes for potential future changes...
- I do not not see any potential user of ptrace_event_pid() outside
of fork.c, so perhaps this helper should not be exported.
In fact I wouldn't mind if you send v5 which moves it into fork.c ;)
On Thu, Apr 3, 2014 at 8:44 AM, Oleg Nesterov o...@redhat.com wrote:
On 04/02, Matthew Dempsky wrote:
When tracing a process in another pid namespace, it's important for
fork event messages to contain the child's pid as seen from the
tracer's pid namespace, not the parent's. Otherwise, the
v4:
- Refactor out ptrace_event_pid() to dedup FIXME code
- Handle task_active_pid_ns() returning NULL
- Use rcu_dereference() for accessing current->parent
v3:
- Respond to Oleg feedback about p possibly already exiting
and adding proper locking
v4:
- Refactor out ptrace_event_pid() to dedup FIXME code
- Handle task_active_pid_ns() returning NULL
- Use rcu_dereference() for accessing current-parent
v3:
- Respond to Oleg feedback about p possibly already exiting
and adding proper locking
-
14 matches
Mail list logo
