Re: [PATCH 2/2] introduce ptrace_reparented() helper

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Roland McGrath
Date: Tuesday, March 4, 2008 - 9:18 pm

> Somehow the patch I sent misses the change in ptrace.c, it can use the

Actually, my pedantic streak prefers that to be in a separate patch.

I think the ptrace_reparented cleanup is fine, it is purely cosmetic and
improves readability.  


This is changing the test from list_empty(&child->ptrace_list)
to child->parent == child->real_parent.  It should indeed be
impossible for those tests not to match.  But, paranoia is its
own reward.  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.  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.


Thanks,
Roland
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 2/2] introduce ptrace_reparented() helper, Oleg Nesterov, (Sun Mar 2, 9:17 pm)
Re: [PATCH 2/2] introduce ptrace_reparented() helper, Oleg Nesterov, (Mon Mar 3, 12:21 am)
Re: [PATCH 2/2] introduce ptrace_reparented() helper, Roland McGrath, (Tue Mar 4, 9:18 pm)
Re: [PATCH 2/2] introduce ptrace_reparented() helper, Oleg Nesterov, (Wed Mar 5, 10:24 am)
Re: [PATCH 2/2] introduce ptrace_reparented() helper, Roland McGrath, (Thu Mar 6, 1:09 am)