> > > We have the tasklist lock. How can there be a race here? The parent
> > > can't detach while we're holding the tasklist lock. If there is a race
> > > with PTRACE_SETOPTIONS, then PTRACE_SETOPTIONS should take the lock.
> > No. If the real parent don't change ->ptrace, it doesn't need
> > lock.
> I don't understand what you mean by that. Do you mean, "if it does
> change ->ptrace, it doesn't need a lock"?
Basically, only tracer can change ->ptrace of traced child. And, it
doesn't need lock. (there are some exceptions)
> > Ah, ok. I think, it's longtime (odd) behavior. And you think, it's
> > a bug. Right?
> > And, both of your and old code has odd behavior. yes?
> Before your patch, do_notify_parent didn't get called; I think that
> perhaps it should be. I'll think about that. After your patch the
> process group will be unexpectedly orphaned, which is not now the case.
> Let me sit on this for a couple of hours. I'll send you an alternative
> patch to look at.
Ok. But I'll sleep soon. So, I'll look it, after having come back from
-- OGAWA Hirofumi <firstname.lastname@example.org> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/