Assert that tracer parent can PT_ATTACH to its child.
This test is for all members of the wait(2) family.
Currently it is marked as an explicit failure PR kern/51621.
I faced the following issues (noted and discussed in the bug report):
- PT_ATTACH seems to work, but waiting for stopped status and signal from the
child results in getting SIGTRAP, not SIGSTOP like in Linux and FreeBSD. This
might be by design, I'm unsure. However, so far I was getting SIGSTOP from a
tracer process that was not the parent. SIGSTOP vs SIGTRAP logic also
complicates the things up as tracer must check whether is a parent for tracee
or not - this shouldn't be needed.
- PT_CONTINUE seems to have no effect at all, the child hangs. This operation
works on Linux and FreeBSD and in the end, test passes correctly.
- Debugging this with gdb(1) results in receiving SIGABRT from the GNU
debugger (in the moment of raising/receiving SIGTRAP). This is making the
things harder in general.
Sponsored by <The NetBSD Foundation>.
before recursing into lower blocks, to make sure that it will be removed after
all its referenced blocks are removed
fixes 'ffs_blkfree_common: freeing free block' panic triggered by
ufs_truncate_retry() when just the upper indirect block registration failed,
code tried to free the lower blocks again after wapbl flush
problem found by hannken@, thank you
(indirect) block before freeing the referenced blocks; it's necessary for
fsck to recover the filesystem, if system goes down during truncate
patch courtesy of hannken@ with only sligh tweaks
This test asserts that any tracer sees process termination before its
parent.
This test is not applicable for wait(2) and wait(3) as these interfaces
cannot get specified process id argument (PID).
Sponsored by <The NetBSD Foundation>.
This change tidies up in6_select* functions, especially
selectroute.
selectroute is annoying because:
- It returns both/either of a rtentry and/or an ifp
- Yes, it may return only an ifp!
- It is valid but selectroute shouldn't handle the case
- Such conditional behavior makes it difficult
to apply locking/psref thingy
- It may return a rtentry even if error
- It may use opt->ip6po_nextroute rtcache implicitly
- The caller can know if it is used
by rtcache_validate(&opt->ip6po_nextroute)
but it's racy in MP-safe world
- Even if it uses opt->ip6po_nextroute, it may
return a rtentry that isn't derived from the rtcache
The change includes:
- Rename selectroute to in6_selectroute
- Let a remaining caller of selectroute, in6_selectif,
use in6_selectroute instead
- Let in6_selectroute return only an rtentry
- If error, it doesn't return an rtentry
- A caller gets an ifp from a returned rtentry
- Allow in6_selectroute to modify a passed rtcache
and a caller can know if opt->ip6po_nextroute is
used via the rtcache
- Let callers (ip6_output and in6_selectif) handle
the case that only an ifp is required
Inspired by OpenBSD
Proposed on tech-kern and tech-net
LGTM by roy@
As the comment "find first available ipv4 address" indicates,
if an IP address is found, we need to leave the two nested loops,
a loop for an interface list and a loop for IP addresses of
an interface. However, the original code broke away only from
the inner loop.
The original (wrong) behavior was non-critical, which just
returned a non-first IP address. Unfortunately, after applying
psref, the behavior may call psref_acquire twice to a target
with the same psref object, resulting in a kernel panic eventually.
Add new tests:
- waitpid_options
- waitid_options
- wait3_options
- wait4_options
- wait6_options
These tests are included in t_wait_noproc and t_wait_noproc_wnohang.
waitpid_options, wait3_options, wait4_options test combinations of options
of: bit for WALLSIG, WALTSIG, __WALL, __WCLONE and later a full combination
mask of WNOWAIT, WEXITED, WUNTRACED, WSTOPPED, WTRAPPED and WCONTINUED.
waitid and wait6 test full combination mask of WNOWAIT, WEXITED, WUNTRACED,
WSTOPPED, WTRAPPED and WCONTINUED -- excluded empty value and singular
WNOWAIT.
For compatibility reasons alter waitid and wait6 to test against options
WEXITED | WTRAPPED, as it's equivalent to waitpid, wait3, wait4.
The intention for these tests it to catch any possible issues with slighty
changed behavior of wait(2)-like functions in terms of valid options
values.
All tests pass successfully.
Sponsored by <The NetBSD Foundation>
Explain why the lock in here needs to be recursive. Related to PR 46997.
ufs_extattr 1.47 was also committed directly here, so this file is still
fully synced with it.
Revert 1.264 - that was intended to fix 51600, but didn't, it just
hid the problem, and caused 51606. This fixes 51606.
Handle waiting on a process that has been detatched from its parent
because of being ptrace'd by some other process. This fixes 51600.
("handle" here means that the wait() hangs, or with WNOHANG, returns 0,
we cannot actually wait on a process that is not currently an attached
child.)
Note: the detatched process waiting is not yet perfect (it fails to
take account of options like WALLSIG and WALTSIG) - suport for those
(that is, ignoring a detatched child that one of those options will
later cause to be ignored when the process is re-attached.)
For now, for ither than when waiting for a specific process ID, when
a process does a wait() sys call (any of them), has no applicable
children attached that can be returned, and has at least one detatched
child, then we do a linear search of all processes to look for a
suitable detatched child. This is likely to be slow - but very rare.
Eventually it might be better to keep a list of detatched children
per process.
