ieee80211_node.h uses LIST_HEAD() which LinuxKPI redefines and this
can lead to problems (see comment there). Make sure the net80211
header file is handled correctly by adding it to the list of files
to include before re-defining the macro.
Also add header files needed as dependencies.
Sponsored-by: The FreeBSD Foundation
MFC-after: 2 weeks
Reviewed-by: philip, hselasky
Differential Revision: https://reviews.freebsd.org/D29336
Both linux/random.h and net80211 have a function named
get_random_bytes(). With overlapping files included these collide.
Arguably the function could be renamed in linuxkpi but the generic
name should also not be used in net80211 so rename it there.
Sponsored-by: The FreeBSD Foundation
MFC-after: 2 weeks
Reviewed-by: philip, adrian
Differential Revision: https://reviews.freebsd.org/D29335
There are scenarios where an NFS client will mount an NFSv4 export
without specifying a callback address.
When running nfsdumpstate under this circumstance, the column output is
shifted incorrectly which places the "ClientID" value underneath the
"Clientaddr" column.
This diff is a small cosmetic change that prints a blank in the
"Clientaddr" column and ensures the data for the columns are aligned
appropriately.
Submitted by: Caleb St. John
Reviewed by: sef (previous version)
MFC after: 3 days
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D18958
"device" is already used as the generic PCI-level name of the device
model to use (e.g. "hostbridge"). The result was that parsing
"hostbridge" as an integer failed and the host bridge used a device ID
of 0. The EFI ROM asserts that the device ID of the hostbridge is not
0, so booting with the current EFI ROM was failing during the ROM
boot.
Fixes: 621b509048
ipf_proxy_check() returns -1 for an error and 0 or 1 for success.
ipf_proxy_check()'s callers check for error and if the return code
is 0, they change it to 1 prior to returning to their callers. Simply
by returning -1 or 1 we reduce complexity and cycles burned changing
0 to 1.
MFC after: 1 week
documention.
Commit SVN r364219 / Git 8a0edc914f changed random(9) to be a shim around
prng32(9) and inadvertently caused random(9) to begin returning numbers in the
range [0,2^32-1] instead of [0,2^31-1], where the latter has been the documented
range for decades.
The increased output range has been identified as the source of numerous bugs in
code written against the historical output range e.g. ipfw "prob" rules and
stats(3) are known to be affected, and a non-exhaustive audit of the tree
identified other random(9) consumers which are also likely affected.
As random(9) is deprecated and slated for eventual removal in 14.0, consumers
should gradually be audited and migrated to prng(9).
Submitted by: Loic Prylli <lprylli@netflix.com>
Obtained from: Netflix
Reviewed by: cem, delphij, imp
MFC after: 1 day
MFC to: stable/13, releng/13.0
Differential Revision: https://reviews.freebsd.org/D29385
3a509754de removed the color field from our definition, but libevent1
has a copy of it off to the side to prevent event.h consumers from
*needing* to pull in sys/queue.h and sys/tree.h.
Update the event.h definition so that we don't accidentally end up with
two different views of struct event.
This appears to have no functional effect on anything in tree, but this
came up in a local patch to port if_switch(4) and related components
from OpenBSD.
MFC after: 1 week
During a recent NFSv4 testing event a test server caused a hang
where "umount -N" failed. The renew thread was sleeping on "nfsv4lck"
and the "umount" was sleeping, waiting for the renew thread to
terminate.
This is the second of two patches that is hoped to fix the renew thread
so that it will terminate when "umount -N" is done on the mount.
This patch adds a 5second timeout on the msleep()s and checks for
the forced dismount flag so that the renew thread will
wake up and see the forced dismount flag. Normally a wakeup()
will occur in less than 5seconds, but if a premature return from
msleep() does occur, it will simply loop around and msleep() again.
The patch also adds the "mp" argument to nfsv4_lock() so that it
will return when the forced dismount flag is set.
While here, replace the nfsmsleep() wrapper that was used for portability
with the actual msleep() call.
MFC after: 2 weeks
An install using -DNO_ROOT emits mtree entries containing tags used by
pkgbase. makefs(8) can safely ignore them, so do that rather than
emitting a warning for each entry.
Reviewed by: brooks, imp
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29384
Just like with the packet counters move the timekeeping information into
dn_cfg. This reduces the global name space use for dummynet and will
make subsequent work to add vnet support and re-use in pf easier.
Reviewed by: donner
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Different Revision: https://reviews.freebsd.org/D29246
Move the packets counters into the dn_cfg struct. This reduces the
global name space use for dummynet and will make future work for things
like vnet support and re-use in pf easier.
Reviewed by: donner
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D29245
Add a -M option to control the maximum length of forwarded messages.
syslogd(8) used to truncate forwarded messages to 1024 bytes, but after
commit 1a874a126a ("Add RFC 5424 syslog message output to syslogd.")
applies a more conservative limit of 480 bytes for IPv4 per RFC 5426
section 3.2. Restore the old default behaviour of truncating to 1024
bytes. RFC 5424 specifies no upper limit on the length of forwarded
messages, while for RFC 3164 the limit is 1024 bytes.
Increase MAXLINE to 8192 bytes to correspond to commit 672ef817a192.
Replaced bootfile[] size for MAXPATHLEN used in getbootfile(3) as a
returned value. Using (MAXLINE+1) as a size for bootfile[] is excessive.
PR: 241937
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D27206
- Defined MAXLINE constant (8192 octets by default instead 2048) for
centralized limit setting up. It sets maximum number of characters of
the syslog message. RFC5424 doesn't limit maximum size of the message.
Named after MAXLINE in syslogd(8).
- Fixed size of fmt_cpy buffer up to MAXLINE for rendering formatted
(%m) messages.
- Introduced autoexpansion of sending socket buffer up to MAXLINE.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D27205
PR: 254419
Reviewed by: gallatin, kp
Tested by: Igor A. Valkov <viaprog@gmail.com>
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29378
Because the ESP mount point (/boot/efi) is in mtree, tar will attempt to
extract a directory at that point post-mount when the system is installed.
Normally, this is fine, since tar can happily set whatever properties it
wants. For FAT32 file systems, however, like the ESP, tar will attempt to
set mtime on the root directory, which FAT does not support, and tar will
interpret this as a fatal error, breaking the install (see
https://github.com/libarchive/libarchive/issues/1516). This issue would
also break scripted installs on bare-metal POWER8, POWER9, and PS3
systems, as well as some ARM systems.
This patch solves the problem in two ways:
- If stdout is a TTY, use the distextract stage instead of tar, as in
interactive installs. distextract solves this problem internally and
provides a nicer UI to boot, but requires a TTY.
- If stdout is not a TTY, use tar but, as a stopgap for 13.0, exclude
boot/efi from tarball extraction and then add it by hand. This is a
hack, and better solutions (as in the libarchive ticket above) will
obsolete it, but it solves the most common case, leaving only
unattended TTY-less installs on a few tier-2 platforms broken.
In addition, fix a bug with fstab generation uncovered once the tar issue
is fixed that umount(8) can depend on the ordering of lines in fstab in a
way that mount(8) does not. The partition editor now writes out fstab in
mount order, making sure umount (run at the end of scripted, but not
interactive, installs) succeeds.
PR: 254395
Reviewed by: gjb, imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D29380
Only attempt to fetch the configuration data and connect the shared
ring once the frontend has switched to the 'Connected' state. This
seems to be inline with what Linux netback does, and is required to
make newer versions of NetBSD netfront work, since NetBSD only
publishes the required configuration before switching to the Connected
state.
MFC after: 1 week
Sponsored by: Citrix Systems R&D
Make it easy to define interceptors for new sanitizer runtimes, rather
than assuming KCSAN. Lay a bit of groundwork for KASAN and KMSAN.
When a sanitizer is compiled in, atomic(9) and bus_space(9) definitions
in atomic_san.h are used by default instead of the inline
implementations in the platform's atomic.h. These definitions are
implemented in the sanitizer runtime, which includes
machine/{atomic,bus}.h with SAN_RUNTIME defined to pull in the actual
implementations.
No functional change intended.
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
In both cases, too few frames were trimmed, leading to exception handling
or DTrace internals being exposed in stack traces exposed by D's stack()
primitive.
MFC after: 3 days
Reviewed by: emaste, andrew
In particular:
- There is no need to do anything with gpart (the installer does that
for you).
- There is no need to specify the network interface, since we have
an option for defaults.
After increasing the lib/msun/tests WARNS to 6, this triggers a
compilation error for RISC-V.
Fixes: 87d65c747a ("lib/msun: Allow building tests with WARNS=6")
Reported by: Jenkins
This avoids mixing the use of two different enums which modern C
compilers warn about.
Reviewed by: np
MFC after: 2 weeks
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D29301
The LLVM bug was fixed a long time ago and with D29076 this test actually
passes now.
Reviewed By: andrew
Differential Revision: https://reviews.freebsd.org/D29092
If long double has more than 64 mantissa bits, using uint64_t to hold the
mantissa bits will truncate the value and result in test failures. To fix
this problem use __uint128_t since all platforms that have
__LDBL_MANT_DIG__ > 64 also have compiler support for 128-bit integers.
Reviewed By: rlibby
Differential Revision: https://reviews.freebsd.org/D29076
