After a lot of reading the code and thinking about how it behaves I have
managed to figure out what the current ptrace locking rules are. The
current code is in much better that it appears at first glance. The
troublesome code paths are actually the code paths that violate the current
rules.
ptrace uses simple exclusive access as it's locking. You can only touch
task->ptrace if the task is stopped and you are the ptracer, or if the task
is running and are the task itself.
Very simple, very easy to maintain. It just needs to be documented so
people know not to touch ptrace from elsewhere.
Currently we do have a few pieces of code that are in violation of this
rule. Particularly the core dump code, and ptrace_attach. But so far the
code looks fixable.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
#ifdef __KERNEL__
/*
* Ptrace flags
+ *
+ * The owner ship rules for task->ptrace which holds the ptrace
+ * flags is simple. When a task is running it owns it's task->ptrace
+ * flags. When the a task is stopped the ptracer owns task->ptrace.
*/
#define PT_PTRACED 0x00000001
(thread_group_leader(p) && !thread_group_empty(p))
/*
- * Protects ->fs, ->files, ->mm, ->ptrace, ->group_info, ->comm, keyring
+ * Protects ->fs, ->files, ->mm, ->group_info, ->comm, keyring
* subscriptions and synchronises with wait4(). Also used in procfs. Also
* pins the final release of task.io_context. Also protects ->cpuset.
*