Messages in this thread Patch in this message | | | Date | Wed, 5 Mar 2008 20:24:20 +0300 | From | Oleg Nesterov <> | Subject | Re: [PATCH 2/2] introduce ptrace_reparented() helper |
| |
On 03/04, Roland McGrath wrote: > > > Somehow the patch I sent misses the change in ptrace.c, it can use the > > new helper too. > > Actually, my pedantic streak prefers that to be in a separate patch. > ... > I don't object to the change, but it should be > separate so bisect distinguishes it should it ever turn out to > matter in some way we are now overlooking.
OK, agreed, will do.
> I'd even be a > little inclined towards: > > if (child->real_parent == child->parent) { > BUG_ON(!list_empty(&child->ptrace_list)); > return 0; > } else { > BUG_ON(list_empty(&child->ptrace_list)); > return 1; > } > > except of course you couldn't use that in the reparent_thread case. ^^^^^^^^^^^^^^^ I can't believe. You are reading my mind!
I am planning to do some changes in forget_original_parent (fix 2 very old minor bugs and _perhaps_ add some improvement). I hit the minor but nasty problem: this open coded __ptrace_unlink() in reparent_thread(). _This_ is the actual reason for this patch.
So. Would you object if I do
--- kernel/ptrace.c 2008-03-03 17:01:06.000000000 +0300 +++ kernel/ptrace.c 2008-03-05 20:22:44.801142777 +0300 @@ -67,11 +67,12 @@ void ptrace_untrace(struct task_struct * * remove it from the ptrace list. * * Must be called with the tasklist lock write-held. + * + * Either the caller is ptracer, or the caller is ->real_parent + * and the child is not traced. */ void __ptrace_unlink(struct task_struct *child) { - BUG_ON(!child->ptrace); - child->ptrace = 0; if (ptrace_reparented(child)) { list_del_init(&child->ptrace_list);
?
Oleg.
| |