On 13.11.2016 03:39, Robert Elz wrote: > Date: Sun, 13 Nov 2016 02:44:03 +0100 > From: Kamil Rytarowski <n54%gmx.com@localhost> > Message-ID: <332a57da-1ac6-38ed-4fc3-947e2e6ca437%gmx.com@localhost> > > | I can add a test for it, comparing old parent identifier with p_ppid > | from kinfo_proc2. > > That would be useful, I suspect they will be the same except when the > process is being traced. > Done! > | Another place with ppid is in procfs: /proc/<pid>/stat > | The 4th field should be PPID. > > That one comes from p_ppid .. so will also probably be (currently) incorrect > for a traced process, so a test would be good to verify. That could also be > fixed by using the new kern_getppid() or by just not changing p_ppid in > proc_reparent() if no-one can find a reason why the change is needed. > > As best I can tell, p_ppid is used excludively for providing info to userland, > and the info wanted is always the original parent's pid, so changing it > doesn't make a lot of sense to me. > > kre > I have added two tests: attach6 and attach7, in t_ptrace_wait*. The former tests sysctl(7) and struct kinfo_proc2 and the latter /proc/curproc/status. As of now, both tests fail for me. I will wait for releng test bots to confirm it. There is a side topic. how useful is /proc, as it was implemented in order to address old (4.4BSD as far as I know) defects in ptrace(2). The deficiencies have been addressed long time ago and the duplicated interface is still there. For now I will just ignore procfs, I'm just wondering whether there are still users of it.
Attachment:
signature.asc
Description: OpenPGP digital signature