Re: [PATCH 2/2] ptrace children revamp

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Roland McGrath
Date: Wednesday, April 9, 2008 - 1:15 pm

> Heh. You are right, the current kernel has the same (minor) bug.

I have a regression test program for that (the one I sent you).
I've done a fix as a follow-on patch.


(Yes!)  Ah, thanks for that.  I wrote a regression test program for this
case that worked before and fails with my last version of the patch.
I've fixed my new code so it passes again.


I'm pretty sure it doesn't matter in real life.  I doubt whoever uses
__WNOTHREAD was relying on seeing some other thread's reparented
children.  TBH, I don't care much about __WNOTHREAD and I don't know off
hand of anything that actually uses it.  OTOH, an extra wakeup on
wait_chldexit is always harmless.  And for pure anality, it seems proper
to maintain the invariant that do_wait() wakes up promptly whenever
interrupting and restarting it would complete without blocking.  But, we
don't get that wakeup now and noone has complained, so all in all, I'm
inclined to leave it as it is.

I've put the latest tweaked version of this same patch series at:
	http://people.redhat.com/roland/kernel-patches/ptrace-cleanup.mbox
That adds a fourth patch that fixes the aforementioned bug case that the
current canonical kernel gets wrong.  I think that fix also incidentally
covered the init-ignores-SIGCHLD case, but I didn't test that and I'm
not really positive.

I'm working on a variant of the ptrace revamp where all ptrace'd tasks
go on a list (whether natural children or not).  (This was my original
intent, but then I thought it might be more complication and change that
way.  Now it's seeming attractive again.)  I tend towards this approach
aesthetically because it makes ptrace bookkeeping more consistent across
all kinds of tracees.  For the cases we've been talking about, it means
ptrace_exit() would take care of zombies kept alive by ptrace uniformly
before we get to the reparent_thread loop.  This means the init case is
separate and needs a separate fix, but that kind of seems cleaner.  When
I get the variant patch working, we can see which one looks best.  I'd
like your opinion on that.


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

Messages in current thread:
[PATCH 1/2] do_wait reorganization, Roland McGrath, (Fri Mar 28, 8:34 pm)
[PATCH 2/2] ptrace children revamp, Roland McGrath, (Fri Mar 28, 8:35 pm)
Re: [PATCH 1/2] do_wait reorganization, Oleg Nesterov, (Sat Mar 29, 3:35 am)
Re: [PATCH 2/2] ptrace children revamp, Oleg Nesterov, (Sat Mar 29, 3:39 am)
Re: [PATCH 2/2] ptrace children revamp, Oleg Nesterov, (Sat Mar 29, 6:10 am)
Re: [PATCH 2/2] ptrace children revamp, Oleg Nesterov, (Sat Mar 29, 7:37 am)
Re: [PATCH 1/2] do_wait reorganization, Linus Torvalds, (Sat Mar 29, 9:16 am)
Re: [PATCH 1/2] do_wait reorganization, Roland McGrath, (Sun Mar 30, 8:27 pm)
Re: [PATCH 1/2] do_wait reorganization, Roland McGrath, (Sun Mar 30, 8:54 pm)
[PATCH 1/3] do_wait reorganization, Roland McGrath, (Sun Mar 30, 8:57 pm)
[PATCH 2/3] ptrace children revamp, Roland McGrath, (Sun Mar 30, 8:59 pm)
Re: [PATCH 1/3] do_wait reorganization, Oleg Nesterov, (Mon Mar 31, 1:51 am)
Re: [PATCH 2/3] ptrace children revamp, Oleg Nesterov, (Mon Mar 31, 2:12 am)
Re: [PATCH 1/3] do_wait reorganization, Oleg Nesterov, (Mon Mar 31, 1:07 pm)
Re: [PATCH 1/3] do_wait reorganization, Roland McGrath, (Mon Mar 31, 1:29 pm)
Re: [PATCH 2/2] ptrace children revamp, Roland McGrath, (Fri Apr 4, 2:00 pm)
Re: [PATCH 2/2] ptrace children revamp, Oleg Nesterov, (Sat Apr 5, 7:06 am)
Re: [PATCH 2/2] ptrace children revamp, Roland McGrath, (Wed Apr 9, 1:15 pm)
Re: [PATCH 2/2] ptrace children revamp, Oleg Nesterov, (Sun Apr 13, 7:24 am)
Re: [PATCH 2/2] ptrace children revamp, Roland McGrath, (Mon Apr 14, 6:41 pm)