Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > This patch enables debugger to examine original parent of traced
> > process. That information is not available elsewhere.
>
> So how does ps get it then...
It doesn't. ps reports the tracing process as the parent, rather than
reporting the original parent as the parent. AFAIK, ps gets its info from
/proc, and you can verify that every occurrence of 'pptr' in the proc code is
'p_pptr' (referring to the parent) rather than p_opptr (referring to the
original parent).
[The only times when p_pptr != p_opptr is when a PTRACE_ATTACH happened, or
when CLONE_PTRACE was used.]
Although I'm the author of the patch, I don't think it's really the ultimate
correct solution to the problem. The correct solution, IMHO, is (within
userland) to always report the original parent in places where the parent is
currently being reported. This preserves the illusion that ptracing isn't
happening, for processes that don't care or need to know about it. For
processes that really *do* need to know, there should be a "special" way of
finding out--a new file in proc, maybe, or a new syscall or new ptrace
subcommand.
Since the full "correct" solution isn't required for SUBTERFUGUE, and since
I've heard that small, simple patches are easier to get into the kernel, I
just used a minimal solution.
> This seems surplus
As above, it's not. As far as I can tell, there's simply no other way of
finding this information out, short of dredging through kcore or something
similarly hideous.
--Mike
-- Any sufficiently adverse technology is indistinguishable from Microsoft.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:21 EST