Swap the order of looking into zombie and all process lists, start now
with the zombie one. This prevents a race observed previously that the
same process could be detected on both lists during a single polling call.
While there:
- Short-circuit break for KERN_PROC_PID, once a pid has been detected.
- Removal of redundant "if (kbuf)" and "if (marker)" checks.
- Update of comments regarding potential optimization, explaining why we
don't want to it as of now. Performance gain from lookup call vs
iteration over a list is neglible on a regular system.
- Return ESRCH when no results have been found. This allows more easily
to implement a retry or abandon algorithm.
This corrects races observed in the existing ATF ptrace(2) tests, related
to await_zombie(). This function was expecting to check whether a process
has been transformed into a zombie, however it was causing occasional
crashes as it was overflowing the return buffer, returning the same pid
twice: once from allproc list and the second time from zombieproc one.
Fix suggested by <christos>
Short-circuit break suggested by <kre>
Discussed on tech-kern.
Sponsored by <The NetBSD Foundation>
That is, there was a comment "Ditto" - which once upon a time, was used
to indicate the the previous comment applied here as well. Time passed,
and software mutated, and the previous comment was unfortunately sacrificed.
Poor little Ditto was left all alone.
Noticed while doing some software archaeology.
As a component of atan2(y, x), the case of x == 1.0 is farmed out to
atan(y). The current implementation of this comparison is vulnerable
to signed integer underflow (that is, undefined behavior), and it's
performed in a somewhat more complicated way than it need be. Change
it to not be quite so cute, rather directly comparing the high/low
bits of x to the specific IEEE-754 bit pattern that encodes 1.0.
ok martin@ pgoyette@ maya@
obtained from FreeBSD
