The emulator-portinstall target now unconditionally ensures that qemu
is installed; but is only invoked if needed (aka. when cross building
VM images).
MFC After: 3 days
MFC With: 97bd53ef4d ("Fix duplicate rc.conf files")
The link count for a UFS/FFS inode is stored in a signed 16-bit
integer. Thus the maximum link count has been 32767.
This limit has been recently hit by the poudriere build system when
doing a ports build as it needs one directory per port and the
number of ports recently passed 32767.
A long-term solution would be to use one of the spare 32-bit fields
in the inode to store the link count. However, the UFS1 format does
not have a spare and adding the spare in UFS2 would make it hard
to make it compatible when running on older kernels that use the
original link count field. So this patch uses the much simpler
approach of changing the existing link count field from a signed
16-bit value to an unsigned 16-bit value. It has the fewest lines
of code changes. The only thing that changes is the type in the
dinode and inode structures and the definition of UFS_LINK_MAX. It
has the added benefit that it works with both UFS1 and UFS2.
It allows easy backward compatibility. Indeed it is backward
compatibility that is the primary reason to go with this approach.
If a filesystem with the new organization is mounted on an older
kernel, it still needs to work. Thus if we move the new link count
to a new field, we still need to maintain the old link count as
best as possible even when running on a kernel that knows about the
larger link counts. And we would have to carry this overhead for
the indefinite future.
If we have a new link-count field, we will have to add a new
filesystem flag to indicate that we are running with larger link
counts. We will also need to add of one of the new-feature flags
to say that we have larger link counts. Older kernels clear the
new-feature flags that they do not know about, so when a filesystem
is used on an older kernel and then moved back to a newer one, the
newer one will know that the new link counts have not been maintained
and that it will be necessary to run a full fsck on the filesystem
to correct the link counts before it can be mounted.
With this change, older kernels will generally work with the bigger
counts. While it will not itself allow the link count to exceed
32767, it will have no problem working with inodes that have a link
count greater than 32767. Since it tests that i_nlink <= UFS_LINK_MAX,
counts that are bigger than 32767 will appear negative, so will
still pass the test. Of course, if they ever drop below 32767, they
will no longer be able to exceed 32767. The one issue is if the
link count ever exceeds 65535 then it will wrap to zero and the
older kernel will be none the wiser. But this corner case is likely
to be very rare since these kernels and the applications running
on them do not expect to be able to get link counts over 32767. And
over time, the use of new filesystems on older kernels will become
rarer and rarer.
Reported-by: Mark Millard running poudriere on the ports tree
Reviewed-by: kib, olce.freebsd_certner.fr
Tested-by: Peter Holm, Mark Millard
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D42767
if `first_guess' is zero then main() assumes that locate_hunk has failed
and aborts the patch operation. Instead, make sure to return 1 (the
line number) so that the patch operation can continue.
Issue originally found by Neels Hofmeyr in the regress suite of the diff
implementation for got, where the tests assume that applying a diff with
`patch' and then again with `patch -R' yields back the original file.
Obtained from: OpenBSD (CVS patch.c,v 1.71)
Previously we were trying to set hca_cap_2 without checking if
sw_vhca_id_valid max value, which is the only settable value inside
hca_cap_2, and seeing that we dont have driver support for sw_vhca_id
yet there is no need to set hca_cap_2 at all, it is enough to query it.
Fixes: 7b959396ca ("mlx5: Introduce new destination type TABLE_TYPE")
MFC after: 3 days
when ntpd is enabled.
The leap-seconds.list is used exclusively by ntpd, therefore, do not bother
to perform the fetch when ntpd is not enabled.
PR: conf/275419
Reviewed by: cy, michaelo, imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42875
In order to avoid running into the default net.local.dgram.maxdgram
of 2K currently when calling sendto(2) try to set the sndbuf size to
the maximum ctrl message size.
While on 14 and 15 this does not actually raise the limit anymore (and
be7c095ac9 raised it for syslogd and this),
FreeBSD 13 still requires this change and it will work as expected there.
In addition we always ensure a large enough send buffer this way
independent of kernel defaults.
The problem occured, e.g., when the scan_list result had enough BSSIDs
so the text output would exceed 2048 bytes.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
PR: 274990
Reviewed by: cy, adrian (with previous comment)
Differential Revision: https://reviews.freebsd.org/D42558
Inherit the setting from the listener socket in syncache_socket.
MFC after: 2 weeks
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D42874
We have the mechanism in place to support encoding system registers
explicitly, so use that rather than requiring LLVM 13+, which breaks our
current set of GitHub CI builds.
Fixes: 9eecef0521 ("Add an Armv8 rndr random number provider")
This is important for wpa_supplicant operation on a crowded network.
Note: we actually need an API to increase maximum datagram size on a
socket. Previously SO_SNDBUF magically acted like that, but that was
an undocumented "feature".
Also move the comment to the proper line. Previously it was the receive
buffer that imposed the limit. Now notion of buffer size and maximum
datagram are separate.
Reviewed by: bz, tuexen, karels
Differential Revision: https://reviews.freebsd.org/D42830
PR: 274990
Fix defines and structures to use proper types.
Bring in basic ni->sta synchronization, some channel width handling,
and overload the net80211 functions so that we can talk to
driver/firmware to setup parameters. We will likely not need one
or two of those but it is good for tracing currently.
Cover HT and bits of VHT code in LinuxKPI behind apropriate #ifdef
which are currently not enabled (like LKPI_80211_HW_CRYPTO) until
confirmed to work.
Last, IEEE80211_AMPDU_RX_START made some firmware unhappy.
This will allow others to work on it and test as well.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
The various time fields are time_t's which are only 32-bit on i386.
Fixing the old versions is probably of little use, but it's more correct
and in theory there could be powerpc binaries from 6.x.
PR: 240035
Fixes: fbb273bc05 Properly support for FreeBSD 4 32bit System V shared memory.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D42870
This is needed to support the bhyve gdb stub implementation on arm64.
Reviewed by: andrew
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D42867
mlme_assoc is a tool to trigger net80211::ieee80211_sta_join1() calls
which in certain conditions cause problems to the LinuxKPI 802.11 compat
code (but also believed to possibly cause problems in case of race to
other firmware based drivers). This has proven to be a good reproducer
for the problem even on setups which otherwise could run for days without
hitting it.
Sponsored by: The FreeBSD Foundation
PR: 271979
Some of the I2C ioctl request structures contain pointers and need to
handle requests from 32-bit applications on 64-bit kernels.
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D42836
This tests that with RTLD_DEEPBIND, symbols are looked up in all of the
object's needed objects before the global object.
PR: 275393
Reviewed by: kib
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D42843
This reverts commit b65f813c1a.
As a side effect this also seems to fix wtap which seems to have
lost the epoch over the input path in between.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Move the net_epoch into net80211 around the if_input calls and out of
the driver (in this first case LinuxKPI). This reduces coverage but
also allows us to alloc in calls like (*ampdu_rx_start) which do not
actually pass data up the stack.
The follow-up commits will revert b65f813c1a,
21c4082de9,
17c328b6ae,
af2441fbc7,
and 6c3e93cb5a for ath.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested by: few (rtwn, ath, iwlwifi, ...)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D42427
The CLDR specification [1] defines three possible month formats:
- Abbreviation (e.g Jan, Ιαν)
- Full (e.g January, Ιανουαρίου)
- Standalone (e.g January, Ιανουάριος)
Many languages use different case endings depending on whether the month
is referenced as a standalone word (nominative case), or in date context
(genitive, partitive, etc.). sort(1)'s -M option currently sorts months
by testing input against only the abbrevation format, which is
essentially a substring of the full format. While this works fine for
languages like English, where there are no cases, for languages where
there is a different case ending between the abbreviation/full and
standalone formats, it is not sufficient.
For example, in Greek, "May" can take the following forms:
Abbreviation: Μαΐ (genitive case)
Full: Μαΐου (genitive case)
Standalone: Μάιος (nominative case)
If we use the standalone format in Greek, sort(1) will not able to match
"Μαΐ" to "Μάιος" and the sort will fail.
This change makes sort(1) test against all three formats. It also works
when the input contains mixed formats.
[1] https://cldr.unicode.org/translation/date-time/date-time-patterns
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D42847
Moving lrd sysctl to the tcp.sack branch, since LRD only works with SACK.
Remove the sockopt to programmatically control LRD per session.
Reviewed By: #transport, tuexen, rrs
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D42851
before starting the walk over the global list. Effectively we visit
needed objects first as well, instead of just the object itself.
This seems to better match the semantic offered by the glibc flag.
Reported by: kevans
PR: 275393
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D42841
OpenSSL provides implementations of several AES modes which use
bitslicing and can be accelerated on CPUs which support the NEON
extension. This patch adds arm platform support to ossl(4) and provides
an AES-CBC implementation, though bsaes_cbc_encrypt() only implements
decryption. The real goal is to provide an accelerated AES-GCM
implementation; this will be added in a subsequent patch.
Initially derived from https://reviews.freebsd.org/D37420.
Reviewed by: jhb
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D41304
gcm_*_aesni() are used when the AVX512 implementation is not available.
Fix two bugs which manifest when handling operations spanning multiple
segments:
- Avoid underflow when the length of the input is smaller than the
residual.
- In gcm_decrypt_aesni(), ensure that we begin the operation at the
right offset into the input and output buffers.
Reviewed by: jhb
Fixes: 9b1d87286c ("ossl: Add a fallback AES-GCM implementation using AES-NI")
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42838
Just like it was done for accept(2) in cfb1e92912, use same approach
for two simplier syscalls that return socket addresses. Although,
these two syscalls aren't performance critical, this change generalizes
some code between 3 syscalls trimming code size.
Following example of accept(2), provide VNET-aware and INVARIANT-checking
wrappers sopeeraddr() and sosockaddr() around protosw methods.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D42694
Let the accept functions provide stack memory for protocols to fill it in.
Generic code should provide sockaddr_storage, specialized code may provide
smaller structure.
While rewriting accept(2) make 'addrlen' a true in/out parameter, reporting
required length in case if provided length was insufficient. Our manual
page accept(2) and POSIX don't explicitly require that, but one can read
the text as they do. Linux also does that. Update tests accordingly.
Reviewed by: rscheff, tuexen, zlei, dchagin
Differential Revision: https://reviews.freebsd.org/D42635
Lost Retransmission Detection was added as a
feature in May 2021, but disabled by default.
Enabling the feature by default to reduce the
flow completion time by avoiding RTOs when
retransmissions get lost too.
Reviewed By: tuexen, #transport, zlei
MFC after: 10 weeks
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D42845
Add a function like kva_alloc that allows us to specify the alignment
of the virtual address space returned.
Reviewed by: alc, kib, markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D42788
The kernel_arena used in kva_alloc has the qcache disabled. vmem_alloc
will first try to use the qcache before falling back to vmem_xalloc.
Rather than trying to use the qcache in vmem_alloc just call
vmem_xalloc directly.
Reviewed by: alc, kib, markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D42831
Currently, a prison in "dying" state (removed but still holding
resources) can be brought back to alive state via "jail -d", or
the JAIL_DYING flag to jail_set(2). This seemed like a good idea
at the time.
Its main use was to improve support for specifying the jid when
creating a jail, which also seemed like a good idea at the time.
But resurrecting a jail that was partway through thr process of
shutting down is trouble waiting to happen.
This patch deprecates that flag, leaving it as a no-op for creating
jails (but still useful for looking at dying jails). It sill allows
creating a new jail with the same jid as a dying one, but will renumber
the old one in that case. That's imperfect, but allows for current
behavior.
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D28150
Some of the SMB ioctl request structures contain pointers and need to
handle requests from 32-bit applications on 64-bit kernels.
Obtained from: Juniper Networks, Inc.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D42837