1b4701fe kib June 13, 2022, 7:30 p.m.
markj wrote:
tdsendsignal() may unsuspend a target thread. I think there is at least
one bug there: suppose thread T is suspended in
thread_single(SINGLE_ALLPROC) when trying to kill another process with
REAP_KILL. Suppose a different thread sends SIGKILL to T->td_proc. Then,
tdsendsignal() calls thread_unsuspend(T, T->td_proc). thread_unsuspend()
incorrectly decrements T->td_proc->p_suspcount to -1.

Later, when T->td_proc exits, it will wait forever in
thread_single(SINGLE_EXIT) since T->td_proc->p_suspcount never reaches 1.

Since the thread suspension is bounded by time needed to do
thread_single(), skipping the thread_unsuspend_one() call there should
not affect signal delivery if this thread is selected as target.

Reported by:	markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310
cgit
b9009b17 kib June 13, 2022, 7:30 p.m.
Reviewed by:	markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310
cgit
4493a13e kib June 13, 2022, 7:30 p.m.
Since both self single-threading and remote single-threading rely on
suspending the thread doing thread_single(), it cannot be mixed: thread
doing thread_suspend_switch() might be subject to thread_suspend_one()
and vice versa.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310
cgit
dd883e9a kib June 13, 2022, 7:30 p.m.
suspended for SINGLE_ALLPROC mode.  There is no need to check for
boundary state.  It is only required to see that the suspension comes
from the ALLPROC mode.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310
cgit
b9893b35 kib June 13, 2022, 7:30 p.m.
In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310
cgit
d7a9e6e7 kib June 13, 2022, 7:30 p.m.
to avoid ALLPROC mode to try to race with any other single-threading
mode.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310
cgit
02a2aacb kib June 13, 2022, 7:30 p.m.
Places that will wait for curproc->p_singlethr to become zero (in the
next commit, the counter of number of external single-threading is
to be introduced), must wait for it interruptible, otherwise we
deadlock.  On the other hand, a signal delivered during this window,
if directed to the waiting thread, would cause the wait loop to become
a busy loop.

Since we are exiting, it is safe to ignore the signals.

Reviewed by:	markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310
cgit
d3000939 kib June 13, 2022, 7:30 p.m.
before the process itself does thread_single(SINGLE_EXIT).  We cannot
single-thread such process in ALLPROC (external) mode, and properly
detect and report the failure to do so due to the process becoming
zombie is easier to prevent than handle.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310
cgit
6a025399 asomers June 13, 2022, 7:27 p.m.
If installing from the DVD, mount its packages in the chroot at
/dist/packages.  That way they'll be accessible to an install script.

MFC after:	2 weeks
Sponsored by:	Axcient
Reviewed by:	gjb
Differential Revision: https://reviews.freebsd.org/D35330
cgit
f92e0d6a emaste June 13, 2022, 6:57 p.m.
As with i386 and amd64, "latest" packages are available on stable
branches for arm64/aarch64.

Reviewed by:	manu
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D35445
cgit
9f48eea3 vangyzen June 13, 2022, 1:54 p.m.
Addition to D31491 in order to actually resolve the top root cause.

Currently rpcbind gets contact address from connectionless xprt->xp_p2
member of a transport and will fail to get it when working over
connection oriented transport, leading to a guess game in terms of
contact address on rpcinfo requests like RPCBPROC_GETVERSADDR or
RPCBPROC_GETADDRLIST and poor returns which may influence a user
of a call and specifically reported on OSX clients, which tend to
not provide address hint from rpcinfo request to a server.

MFC after:	1 week
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D35220
cgit
5ea3094e brooks June 13, 2022, 5:35 p.m.
Install the i386 md_var.h under /usr/include/i386 on amd64 and include
when targeting i386.

This is a mostly kernel-only header required by procstat's ZFS support.
It is pulled in by the i386 machine/counter.h.

Reviewed by:	jhb, imp
cgit
8dc3fdfe brooks June 13, 2022, 5:35 p.m.
Install the i386 counter.h under /usr/include/i386 on amd64 and include
when targeting i386.

This is a kernel-only header required by procstat's ZFS support.

Reviewed by:	jhb, imp
cgit
9f7588dd brooks June 13, 2022, 5:35 p.m.
Install the i386 pcpu_aux.h under /usr/include/i386 on amd64 and include
when targeting i386.

This is a kernel-only header that is required by procstat's ZFS support.

Reviewed by:	jhb, imp
cgit
f6fada5e brooks June 13, 2022, 5:35 p.m.
Install the i386 pcpu.h under /usr/include/i386 on amd64 and include
when targeting i386.

This is a kernel-only header and should not be required, but
procstat's zfs support includes this with _KERNEL defined.

Reviewed by:	jhb, imp
cgit