2011-06-08 16:34:03

by Denys Vlasenko

[permalink] [raw]
Subject: [PATCH] make former thread ID available via PTRACE_GETEVENTMSG after PTRACE_EVENT_EXEC stop

Hi Oleg,

As discussed, the attached patch allows tracer to figure out
which of its potentially many tracees performed an execve,
and what was its former tid.

Not sure what kind of locking, if any, I need to put around
current->parent...

The patch is on top of Tejun's patches.

--
vda


Attachments:
pass_old_pid_on_PTRACE_EVENT_EXEC.patch (1.20 kB)

2011-06-08 18:22:10

by Oleg Nesterov

[permalink] [raw]
Subject: Re: [PATCH] make former thread ID available via PTRACE_GETEVENTMSG after PTRACE_EVENT_EXEC stop

On 06/08, Denys Vlasenko wrote:
>
> Not sure what kind of locking, if any, I need to put around
> current->parent...

Yes ;)

> @@ -1383,8 +1383,10 @@ int search_binary_handler(struct linux_binprm *bprm,struct pt_regs *regs)
> */
> bprm->recursion_depth = depth;
> if (retval >= 0) {
> - if (depth == 0)
> - tracehook_report_exec(fmt, bprm, regs);
> + if (depth == 0) {
> + pid_t pid = task_pid_nr_ns(current, task_active_pid_ns(current->parent));

It is not safe to use ->parent. At least you need rcu lock around.

Also. At this point current has already changed its pid, you should
record pid_t before ->load_binary().

And. We have the coding style police, please use scripts/checkpatch.pl



Just in case, I'll be off-line till Monday.

Oleg.