[PATCH] ptrace: document the locking rules
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>
This commit is contained in:
parent
4a4b69f79b
commit
260ea10132
2 changed files with 5 additions and 1 deletions
|
@ -51,6 +51,10 @@
|
|||
#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
|
||||
|
|
|
@ -1225,7 +1225,7 @@ static inline int thread_group_empty(task_t *p)
|
|||
(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.
|
||||
*
|
||||
|
|
Loading…
Reference in a new issue