Running the test suite yields:
lock order reversal:
1st 0xfffff80004bc6700 unp (unp, sleep mutex) @ sys/kern/uipc_usrreq.c:390
2nd 0xffffffff81a94b30 unp_link_rwlock (unp_link_rwlock, rw) @ sys/kern/uipc_usrreq.c:2934
lock order unp -> unp_link_rwlock attempted at:
0xffffffff80bc216e at witness_checkorder+0xbbe
0xffffffff80b493a5 at _rw_wlock_cookie+0x65
0xffffffff80c0a8e2 at unp_discard+0x22
0xffffffff80c0a888 at unp_freerights+0x38
0xffffffff80c09fdd at unp_scan+0x9d
0xffffffff80c0f9a7 at uipc_sosend_dgram+0x727
0xffffffff80c00a79 at sousrsend+0x79
0xffffffff80c072d0 at kern_sendit+0x1c0
0xffffffff80c074d7 at sendit+0xb7
0xffffffff80c076f3 at sys_sendmsg+0x63
0xffffffff8104d957 at amd64_syscall+0x6b7
0xffffffff8101f9eb at fast_syscall_common+0xf8
This happens when uipc_sosend_dgram() discards a control message because
the receive socket buffer is full. The overflow handling frees
internalized file references in the socket buffer before freeing mbufs.
It does this with socket PCBs locked, leading to the LOR. Defer
handling of file references until the PCBs are unlocked.
Reviewed by: glebius
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41884
hdac_attach() registers an interrupt handler before allocating various
driver resources which are accessed by the interrupt handler. On some
platforms we observe what appear to be spurious interrupts upon a cold
boot, resulting in panics.
Partially work around the problem by deferring irq allocation until
after other resources are allocated. I think this is not a complete
solution, but is correct and sufficient to work around the problems
reported in the PR.
PR: 268393
Tested by: Alexander Sherikov <asherikov@yandex.com>
Tested by: Oleh Hushchenkov <o.hushchenkov@gmail.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41883
Compiler memory barriers do not prevent the CPU from executing the code
out of order. Switch to C11 atomics. This also lets us get rid of the
mutex; instead, loop until the compare_exchange succeeds.
While here, change the return value of at_quick_exit() on failure to
the more traditional -1, matching atexit().
Sponsored by: Klara, Inc.
Reviewed by: Olivier Certner, kevans, kib
Differential Revision: https://reviews.freebsd.org/D41936
Don't recompute mpte during promotion.
Optimize MADV_WILLNEED on existing superpages.
Standardize promotion conditions across amd64, arm64, and i386.
Stop requiring the accessed bit for superpage promotion.
Tidy up pmap_promote_pde() calls.
Retire PMAP_INLINE. It's no longer used.
Note: Some of these changes are a prerequisite to fixing a panic that
arises when attempting to create a wired superpage mapping by
pmap_enter(psind=1) (as opposed to promotion).
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41944
When we're suspending, we get messages about waiting for the controller
to reset. These are in error: we're not waiting for it to reset. We put
the recovery state as part of suspending, so we should suppress these as
a false positive.
Also remove a stray debug that's left over from earlier versions of
the recovery code that no longer makes sense.
Sponsored by: Netflix
- cast GETNEXT to unsigned where it is being promoted to int to prevent
sign-extension (really it would have been better for PEEK*() and
GETNEXT() to return unsigned char; this would have removed a ton of
(uch) casts, but it is too intrusive for now).
- fix an isalpha that should have been iswalpha
PR: 264275, 274032
Reviewed by: kevans, eugen (previous version)
Obtained from: NetBSD
Differential Revision: https://reviews.freebsd.org/D41947
When both --author and --committer are specified, `git log` requires
both to match. Search only by committer, as it is typically the FreeBSD
committer who will perform the MFC.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41964
Start implementing regulatory_hint() using a .c file based allocation
helper function so we could change structures in the future with
better chances to keep compatibility.
This sets wiphy->regd needed by various LinuxKPI based WiFi drivers.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Factor out ieee80211_chanctx_conf into struct lkpi_chanctx in order to
keep local state as well. In first instance that is added_to_drv
only. For now we stay single-chanctx only but this paves the path
to make it a list.
Use the new information to implement ieee80211_iter_chan_contexts_atomic().
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
tid_to_mac80211_ac is an exported symbol in and likely based on iwlwifi,
which leads to a symbol clash in NetBSD. Rename our local LinuxKPI copy
to a better name and add a comment where to find a copy of the mapping
table.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reported by: Phil Nelson (phil netbsd org)
These scripts predate /etc/rc.diskless* and use a different scheme. A
comment was added to them back in 2002 noting they were 3 years old at
that point.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D41951
The following sysctl variables are actually loader tunables. Add sysctl
flag CTLFLAG_TUN to them so that `sysctl -T` will report them correctly.
1. net.inet.ip.fw.enable
2. net.inet6.ip6.fw.enable
3. net.link.ether.ipfw
No functional change intended.
Reviewed by: glebius
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41928
The following sysctl variables are actually loader tunables. Add sysctl
flag CTLFLAG_TUN to them so that `sysctl -T` will report them correctly.
1. net.inet6.ip6.auto_linklocal
2. net.inet6.ip6.accept_rtadv
3. net.inet6.ip6.no_radr
No functional change intended.
Reviewed by: glebius
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41928
The sysctl variable `net.route.netisr_maxqlen` is actually a loader
tunable. Add sysctl flag CTLFLAG_TUN to it so that `sysctl -T` will
report it correctly.
No functional change intended.
Reviewed by: glebius
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41928
Since 13.1, /etc/rc.d/jail has looked for a per-jail config file in
/etc/jail.conf.d. For RELENG 14, the ".include" directive was added to
jail(8), with a sample line in the jail.conf(5) man page that includes
"/etc/jail.conf.d/*.conf".
These two use cases don't work together. When the jail.conf.d files
are included from a master jail.conf, the files in jail.conf.d are
likely to hold only partial configurations, and shouldn't be directly
loaded by rc.d/jail. But there are existing configurations that depend
on the current rc.d behavior. While users could be advised not to
include from /etc/jail.conf.d, it's the natural choice even if not
mentioned in jail.conf.5.
The workaround is for rc.d/jail to continue to load the individual
files, but only when /etc/jail.conf doesn't include from that
directory (via a simple grep test), This allows the current use
while not breaking the previous use.
Reported by: antranigv at freebsd.am
Differential Revision: https://reviews.freebsd.org/D41962
getdirentires last argument "off_t *basep" is an optional output
argument. It returns the value only when the passed-in value(pointer)
is non-NULL.
This is a part of the research work at RCSLab, University of Waterloo.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41969
Currently, when we suspend, we need to tear down all the qpairs. We call
nvme_admin_qpair_abort_aers with the admin qpair lock held, but the
tracker it will call for the pending AER also locks it (recursively)
hitting an assert. This routine is called without the qpair lock held
when we destroy the device entirely in a number of places. Add an assert
to this effect and drop the qpair lock before calling it.
nvme_admin_qpair_abort_aers then locks the qpair lock to traverse the
list, dropping it around calls to nvme_qpair_complete_tracker, and
restarting the list scan after picking it back up.
Note: If interrupts are still running, there's a tiny window for these
AERs: If one fires just an instant after we manually complete it, then
we'll be fine: we set the state of the queue to 'waiting' and we ignore
interrupts while 'waiting'. We know we'll destroy all the queue state
with these pending interrupts before looking at them again and we know
all the TRs will have been completed or rescheduled. So either way we're
covered.
Also, tidy up the failure case as well: failing a queue is a superset of
disabling it, so no need to call disable first. This solves solves some
locking issues with recursion since we don't need to recurse.. Set the
qpair state of failed queues to RECOVERY_FAILED and stop scheduling the
watchdog. Assert we're not failed when we're enabling a qpair, since
failure currently is one-way. Make failure a little less verbose.
Next, kill the pre/post reset stuff. It's completely bogus since we
disable the qparis, we don't need to also hold the lock through the
reset: disabling will cause the ISR to return early. This keeps us from
recursing on the recovery lock when resuming. We only need the recovery
lock to avoid a specific race between the timer and the ISR.
Finally, kill NVME_RESET_2X. It'S been a major release since we put it
in and nobody has used it as far as I can tell. And it was a motivator
for the pre/post uglification.
These are all interrelated, so need to be done at the same time.
Sponsored by: Netflix
Reviewed by: jhb
Tested by: jhb (made sure suspend / resume worked)
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D41866
Until a better arrangment is worked out, guard the setting of
CROSS_TARGET_FLAGS in local.sys.mk with check for DIRDEPS_BUILD.
Using a separate flag for CROSS_TARGET that can be reset by
bsd.compat.mk is probably the right thing.
Mark Johnston