The macro is misleading and of questionable value to begin with.
For starters, it is used for both spinlocks and regular mutexes (the
latter only the in the slow path), which have fundamentally different
requirements on unlock -- spinlocks are guaranteed to not have blocked
waiters and can blindly do a store.
The commentary above the it is also head-scratching:
> Release mtx_lock quickly, assuming we own it.
You can't *just* release a sleepable mutex "quickly". The only legal use
right now is when the turnstile lock is held.
Note that unlock of a sleepable mutex without using RMW atomics is very
much possible and may show up soon (tm).
Sponsored by: Rubicon Communications, LLC ("Netgate")
The .if defined(_MKSHOWCONFIG) covered an unusually large area, so it
should have not been removed in the last commit. I must have tested in
the wrong tree before pushing...
FixeS: 28b858f505
Sponsored by: Netflix
We don't need this, and we don't use this. It's left over from the svn
days. We stopped supporting svn as a project entirely when 12.x went
EOL. And VCS_REVSION isn't in any current ucl file or anywhere else in
the tree.
Sponsored by: Netflix
Reviewed by : kevans, brd
Differential Revision: https://reviews.freebsd.org/D52912
We don't want to put these in clibs (where libc is) since they are not
critical to system operation. Move them to locales, since anyone who
is interested in translated versions of strerror() is going to have
that installed anyway.
While here, add some more documentation to bsd.nls.mk, particularly
the NLSPACKAGE option.
MFC after: 3 seconds
Reviewed by: manu, kib
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D52898
Document descriptions for device drivers always contain registered
trademarks of the manufacturers, but this is not a place for the
registered mark symbol. While here, remove another useless symbol,
the hyphen in the first line comment.
MFC after: 3 days
Replace CD-ROMs with "discs, USBs, or network boot environments"
to both modernize aesthetic and also nudge youths to think at scale.
Since I'm disrupting the flow of these lines anyway, expand the VM
acronym because I think this is one of the first manuals people will
be looking at.
Reset list alignment to seven characters. It was at 19 characters,
and that was not enough to align them all, wasting many extra lines
by crunching all the words over. Seven actually bought us some lines
from six due to avg item size. Tag SPDX.
MFC after: 3 days
Discussed with: ivy, zi
Just like vmxnet3_intr_disable_all, iflib may invoke this routine
before vmxnet3_attach_post() has run, which is before the top-level
shared data area is initialized and the device made aware of it.
MFC after: 1 week
Sponsored by: Dell Inc.
MediaTek mt76 WiFi cards are advertising FLR support but after issuing
a FLR the chipset is gone. Add a quirk so we can disable FLR. The
current reset code will automatically fall back to a power reset.
This makes the card show up under bhyve where before it would just not
be discovered at all. That should make wifibox work for it and will help
development for a LinuxKPI based mt76 driver as found in framework laptops
as no dedicated machine and constant reboots are needed anymore.
We will likely need to add more PCI vendor/device IDs once we can test
the other device IDs.
Event: EuroBSDCon Devsummit 2025
After a lot of help from: jhb
Really implemented by: jhb (I just typed and tested)
GH issue: github.com/pgj/freebsd-wifibox/issues/73
MFC after: 3 days
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D52728
CROSS_TOOLCHAIN is used to build src with a different toolchain than
the bundled one. Ports also has a CROSS_TOOLCHAIN option, but it has
a different meaning. When building ports-mgmt/pkg from ports for the
package-pkg target, unset CROSS_TOOLCHAIN to prevent ports from being
confused.
This fixes 'make CROSS_TOOLCHAIN=llvm19 package-pkg' for the native
target, but cross-building (e.g., targetting powerpc from amd64) is
still broken due to an issue in pkg itself.
MFC after: 3 seconds
Reviewed by: emaste
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D52902
The embedded "SD card" images build very differently from regular
releases, and don't use pkgbase yet.
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Local tree pollution let this escape. *sigh*.
Pointy hat: kevans
Pointy hat: kevans
Pointy hat: kevans
Fixes: 9c7db0931d ("flua: move lposix back into flua for now")
nuageinit largely already did this, but one spot was missed -- add the
necessary require() in to get the module loaded.
Fixes: b11a5709ec ("flua: kick out the remaining builtin modules")
The real luaposix is structured differently, and our builtin version
tends to model that in its own special way. Build it back in until we
get the shlib model just right to unbreak nuageinit, among other things.
This is a partial revert of the below-referenced commit; the other two
modules are simple, though, and were accurately split out.
Reported by: markj
Fixes: b11a5709ec ("flua: kick out the remaining builtin modules")
- Don't clean pkg files, they won't be recorded in the manifest anyway.
- Use pw's new metalog mode to create the vagrant user. Note that we do
not need to manually create the home directory, pw will do it, so just
remove that.
- Write metalog entries for the vagrant user's ssh key dir and
authorized keys file
Note, this depends on an updated pw being installed on the host.
Reviewed by: emaste
MFC after: 1 day
Sponsored by: Klara, Inc.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52631
MD5 is used by libc/resolv to generate a random sequence id from a
current time stamp. Replace this convoluted mechanism with a call
to arc4random(). This permits us to entirely drop MD5 from libc,
simplifying the MD5 rework proposed in D45670.
Approved by: markj
Reviewed by: kevans, markj
See also: D45670
Event: EuroBSDcon 2025
Differential Revision: https://reviews.freebsd.org/D52784
This change includes all necessary changes required to update to OpenSSL
3.5.4.
More information about the 3.5.4 release can be found in the relevant
release notes (see 8e12a5c4eb for more details).
Merge commit '8e12a5c4eb3507846b507d0afe87d115af41df40'
The current iwx_rs_update() code doesn't handle setting VHT rates
at all.
So:
* write a routine - iwx_rs_update_node_txrate() - which will update
the given node txrate info with the given notification
* .. which is based on the print_ratenflags() logic and decoding
* migrate iwx_rs_update() to use this routine, only on the STA BSS node.
This only handles decoding the version 2 rate_n_flags format response -
same as print_ratenflags() - so print if someone somehow sees a version
1 response.
It's shown a few things that deserve some later follow-up work:
* I really should have net80211 APIs that operate on the txrate struct
itself, not on the ieee80211_node, but I'll use what I have.
Changing it later is easy.
* the current net80211 txrate API doesn't include channel width,
LDPC/STBC and such. I didn't need it for the earlier tx rate
representation migration, but it would be nice to add it.
(The reason is that those choices are currently made in the drivers
using rate control, rather than the rate control module, which is
again what the older code did as well.)
This means that the displayed rate isn't EXACTLY what the NIC has
chosen - eg the NIC could quite happily decide to transmit a 20MHz
or 40MHz frame to an 80MHz STA if that actually works out better.
So just add TODOs for those.
Locally tested:
* AX210, STA mode
Differential Revision: https://reviews.freebsd.org/D52767
Reviewed by: thj
iwx is now logging a lot of stuff to the kernel when associated at VHT
rates. It's my fault; the replacement tx rate APIs print out a warning
when you're handing the legacy rate /HT rate APIs a VHT rate.
However all of the supported chipsets in iwx will be pushing the
rate control entirely into firmware. We don't need to do per-frame
TX rate control like in previous chips.
So for now, just put in an if (rate == VHT) into the path and
a TODO comment. A few lines later the function will just skip the
rate assignment stuff for data frames, thus saving us the logging.
The other paths (control traffic, multicast traffic) uses legacy
rates / HT rates by default and won't trigger a warning log.
Yes, iwx_tx_fill_cmd() really does deserve a rate control logic
rewrite, but I want to fix this particular issue first.
Locally tested:
* AX210, STA mode, HT and VHT associations
Differential Revision: https://reviews.freebsd.org/D52766
Reviewed by: thj
The locking paths into these routines LOOK correct, but I figured
it'd be good to at least enforce we're not doing concurrent entry
into iwx_start() / iwx_tx() without the lock held.
Differential Revision: https://reviews.freebsd.org/D52655
Reviewed by: thj
I'm seeing random disconnects in iwx without any useful information
as to why. I'll start by adding missed beacon debugging here; hopefully
they're generally useful.
Differential Revision: https://reviews.freebsd.org/D52524
Reviewed by: bz
While both locking and unlocking a spinlock used to be inline, this
changed when spinlock_enter/spinlock_exit got introduced, defeating the
point of inlining them.
This either needs to have inlined spinlock enter/exit in place or have
mtx lock/unlock as function calls with the irq flags inlined in there.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.
Adjust the stand build now that these three libs have their own new
homes.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51891
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.
Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.
.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.
This re-lands bootstrap module support with a more sensible subset, and
after having verified that it cross-builds fine on macOS and Linux -- we
cannot do libfreebsd on !FreeBSD because it's more system header
dependant. We also need to bootstrap libmd to bring in libhash, and
libucl + libyaml.
Reviewed by: bapt, emaste (both previous version)
Differential Revision: https://reviews.freebsd.org/D51890
This reverts commit 1953a12ee2, because it
cannot work at all on macOS without more work, at a minimum. We use
linker sets for module discovery, but we don't have a version of this
that works for mach-o at the moment.
This is a tarball containing the pkgbase repository for the release.
Note: This is an uncompressed tarball, because all of its constituent
.pkg files are already compressed; there's no point adding another
layer of compression.
Reviewed by: ivy
MFC after: 1 minute
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D52899
In addition to not putting distribution sets onto ISO images, if
NODISTSETS is set then we should not build the distribution sets
or put them onto the "FTP" site (aka download.freebsd.org).
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Treat an empty NODISTSETS the same as if it is not defined; this avoids
problems if a script calls 'make release NODISTSETS=${NODISTSETS}'.
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Add a new --jail option to the pkgbase script which installs
jail-specific set variants if they exist:
* "minimal" is replaced with "minimal-jail"
* A kernel is not installed.
* For sets shown in the component selection dialogue, only show the
appropriate variant (jail or non-jail) for the target.
Modify the jail script to pass --jail to the pkgbase script.
Remove the redundant --no-kernel option, which was added in 15.0 and
was only used to install jails.
MFC after: 3000ms
Reviewed by: ifreund_freebsdfoundation.org
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D52829
In "all pools" mode, pool_iter_refresh() will call zpool_iter(), which
will call zpool_refresh_stats() before calling add_pool(). If we already
have the pool, this is a different handle, so we just release it and
return. Back in pool_iter_refresh(), we then call zpool_stats_refresh()
again for our handle on the same pool.
All together, this means we're doing two ZFS_IOC_POOL_STATS calls into
the kernel for every pool in the system. This isn't wrong, but it does
double the pressure on global locks.
Instead, we add a new function zpool_refresh_stats_from_handle() that
simply copies the pool config and state from one handle to another, and
use it to update our handle before we release it in add_pool(), so we
only have one call per pool per interval.
Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Closes#17807
zpool_iter() passes the callback a new instance of zpool_handle_t each
time, so the existing handle in the pool_list AVL never actually gets a
refresh. Internally, that means its zpool_config is never updated, and
the old config is never moved to zpool_old_config. As a result,
print_iostat() never sees any updated config, and so repeats the first
line forever.
This is the simplest workaround: just don't mark existing pools as
refreshed. pool_list_refresh() will see this and refresh them.
The downside is a second call to ZFS_IOC_POOL_STATS for existing pools,
because zpool_iter() just called it for the handle we threw away.
Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Closes#17807
When skipping the boot row (with -y), the early loop meant we weren't
updating the "last_npools" count. That means the count never advanced
past zero, so cb_iteration was always reset to 0, leading to it being
"stuck" on the boot line, printing the header and nothing else forever.
Updating the pool counter on every loop sorts that out: it advances,
cb_iteration moves properly, and normal rows are printed.
Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Closes#17807
This largely eliminates contention on the vnode interlock.
Note this still does not scale, to be fixed(tm).
Reviewed by: kib
Tested by: pho (previous version)
Differential Revision: https://reviews.freebsd.org/D38761
Vast majority of real-world contention on the hash comes from lookups,
notably seen during highly parallel poudriere runs.
Lockless lookup largely alleviates the problem.
Reviewed by: kib
Tested by: pho (previous version)
Differential Revision: https://reviews.freebsd.org/D38761
While here some style touch ups and fixing a stale name in an assert.
Reviewed by: kib
Tested by: pho (previous version)
Differential Revision: https://reviews.freebsd.org/D38761
Both lower vnode and null data are safe while the lock is held,
at the same time neither is touched after unlock.
While here remove stale comment about interlock handling. It is no
longer legal to pass to unlock.
Reviewed by: kib
Tested by: pho (previous version)
Differential Revision: https://reviews.freebsd.org/D38761
Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.
Adjust the stand build now that these three libs have their own new
homes.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51891
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.
Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.
.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51890
Mateusz Guzik