The comment suggests that this usage is stale. There is no bkl in the
exec path so if there is a race lurking there, the bkl in ptrace is
not going to help in this regard.
Overview of the possibility of "accidental" races this bkl might
protect:
- ptrace_traceme() is protected against task removal and concurrent
read/write on current->ptrace as it locks write tasklist_lock.
- arch_ptrace_attach() is serialized by ptrace_traceme() against
concurrent PTRACE_TRACEME or PTRACE_ATTACH
- ptrace_attach() is protected the same way ptrace_traceme() and
in turn serializes arch_ptrace_attach()
- ptrace_check_attach() does its own well described serializing too.
There is no obvious race here.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Acked-by: Roland McGrath <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Roland McGrath <[email protected]>
struct task_struct *child;
long ret;
- /*
- * This lock_kernel fixes a subtle race with suid exec
- */
- lock_kernel();
if (request == PTRACE_TRACEME) {
ret = ptrace_traceme();
if (!ret)
out_put_task_struct:
put_task_struct(child);
out:
- unlock_kernel();
return ret;
}
struct task_struct *child;
long ret;
- /*
- * This lock_kernel fixes a subtle race with suid exec
- */
- lock_kernel();
if (request == PTRACE_TRACEME) {
ret = ptrace_traceme();
goto out;
out_put_task_struct:
put_task_struct(child);
out:
- unlock_kernel();
return ret;
}
#endif /* CONFIG_COMPAT */