On 13.11.2016 02:44, Kamil Rytarowski wrote: > > > On 13.11.2016 02:39, Robert Elz wrote: >> Date: Sat, 12 Nov 2016 14:42:47 -0500 >> From: "Christos Zoulas" <christos%netbsd.org@localhost> >> Message-ID: <20161112194247.37910FBA6%cvs.NetBSD.org@localhost> >> >> | PR/51624: Return the original parent for a traced process. >> >> Maybe the real bug here was that proc_reparent() is changing the >> child's p_ppid ? >> >> I can see no reason for that, and if it wasn't done, then p_ppid would >> be what is wanted by getppid() without needing kern_getppid() to >> do all that unwind logic (and assiated locting and unlocking to make >> it safe.) >> >> Aside from proc_reparent() the only weirdness I can see with p_ppid are >> in kern_proc.c in fill_eproc() and fill_kproc2(). They both use (and >> continue to use, so the results will be different for a process being >> traced, and the same process when not traced) p_pptr->p_pid rather than >> the simpler p_ppid but I am not sure why (nor what the clients of those >> functions are or what the info is used for, so I am not sure what is correct.) >> >> kre >> > > It's also common to use kinfo_proc2 and extract data from there. There > is one field: > > int32_t p_ppid; /* PID_T: Parent process id */ > > getppid(2) and p_ppid shall be the same. > > I can add a test for it, comparing old parent identifier with p_ppid > from kinfo_proc2. > Another place with ppid is in procfs: /proc/<pid>/stat The 4th field should be PPID. Another idea for a test.
Attachment:
signature.asc
Description: OpenPGP digital signature