Messages in this thread | | | Subject | Re: Allow debuger to examine real parent | From | Mike Coleman <> | Date | 06 Mar 2000 17:03:56 -0600 |
| |
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/
| |