Use a constant input operand instead of an output operand to tell the
compiler about OFFSETOF_MONITORBUF. If we tell it we are writing to
*(u_int *)OFFSETOF_MONITORBUF, it rightly complains, but we aren't. The
memory clobber already covers the necessary semantics for the compiler.
Reviewed by: kib
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D45694
Commit dfaeeacc2c modified clientID handling so that it could be done
with only a mutex lock held when vfs.nfsd.enable_locallocks is 0.
This makes it unsafe to change the setting of vfs.nfsd.enable_locallocks
when nfsd threads are active.
This patch forces all nfsd threads to be blocked when the value
of vfs.nfsd.enable_locallocks is changed, so that it is done safely.
MFC after: 1 month
Describe and link the following functions in the lockgmr API:
- lockmgr_disowned
- lockmgr_lock_flags
- lockmgr_slock
- lockmgr_unlock
- lockmgr_xlock
This is not a complete update of lock.9 but at least covers all the main
lock operations.
Reviewed by: gbe, kib
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D45689
On Feb. 28, a problem was reported on freebsd-stable@ where a
nfsd thread processing an ExchangeID operation was blocked for
a long time by another nfsd thread performing a copy_file_range.
This occurred because the copy_file_range was taking a long time,
but also because handling a clientID requires that all other nfsd
threads be blocked via an exclusive lock, as required by ExchangeID.
This patch allows clientID handling to be done with only a mutex
held (instead of an exclusive lock that blocks all other nfsd threads)
when vfs.nfsd.enable_locallocks is 0. For the case of
vfs.nfsd.enable_locallocks set to 1, the exclusive lock that
blocks all nfsd threads is still required.
This patch does make changing the value of vfs.nfsd.enable_locallocks
somewhat racy. A future commit will ensure any change is done when
all nfsd threads are blocked to avoid this racyness.
MFC after: 1 month
On Feb. 28, a problem was reported on freebsd-stable@ where a
nfsd thread processing an ExchangeID operation was blocked for
a long time by another nfsd thread performing a copy_file_range.
This occurred because the copy_file_range was taking a long time,
but also because handling a clientID requires that all other nfsd
threads be blocked via an exclusive lock, as required by ExchangeID.
This patch adds two arguments to nfsv4_cleanclient() so that it
can optionally be called with a mutex held. For this patch, the
first of these arguments is "false" and, as such, there is no
change in semantics. However, this change will allow a future
commit to modify handling of the clientID so that it can be done
with a mutex held while other nfsd threads continue to process
NFS RPCs.
MFC after: 1 month
VM, BASIC-CI, and BASIC-CLOUDWARE images are published with the
filesystem type (UFS or ZFS) in the file name. For backwards
compatibility we have published the UFS images with no filesystem
in the filename (aka with the same file names as we used before we
supported building ZFS VM images); those are going away now.
This will not be MFCed.
Pax can sometimes loop forever. For example:
$ mkdir -p /tmp/src/foo/bar
$ rm -rf /tmp/dst ; mkdir -p /tmp/dst
$ cd /tmp/src
$ echo 'foo/bar/' | /bin/pax -r -w -d -pe "/tmp/dst"
<looping infinitely>
Here, pax(1) infinitely deletes and re-creates /tmp/dst/foo/bar/.
The problem is that chk_path() (bin/pax/file_subs.c), called from
node_creat() also creates the leaf directory when a trailing '/' appears
in the directory name to create. When the execution goes back from
chk_path() to node_creat(), the function still cannot create the leaf
directory (it has been created by chk_path()), so it unlinks it and
calls node_creat() again. The function re-creates it, and so on...
In node_creat() detect trailing slashes and not create a leaf directory,
but only intermediate ones.
PR: 277060
Reviewed by: imp
Move to trusting C++ environment for thread local storage designation.
Noticed by: brooks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D45663
TinyC doesn't support the .symver assembler directive. Add a generic way
to signal this and use that not to define __sym_() macros that use
it. Only use the __sym_* macros in headers when they are defined (which
currently is only for the qsort_r compat code. Not supporting this for
tcc is fine: It's an edge case for legacy binaries / code anyway which
isn't relevant to tinyc.
Sponsored by: Netflix
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D45651
Ensure that we correctly transfer byte counts if the value exceeds what can be
stored in a single 32-bit counter.
Sponsored by: Rubicon Communications, LLC ("Netgate")
In 2001 when the ACPI timer was introduced, it included code to check
for a bug present in some Pentium II and Pentium III chipsets; if the
bug was found to be present, ACPI-safe (which was slower but had a
workaround for the bug) would be used rather than ACPI-fast (which
read the same timer but without the workaround).
In a8b89dff6a (September 2021) I disabled this check by default,
with a loader tunable available to re-enable it; I announced at the
time that it would go away in FreeBSD 15 if I didn't receive any
reports of problems. I have received no such problems, so this code
is now going away.
The debug.acpi.timer_test loader variable triggered a lengthy (in fact,
infinitely long) test of the ACPI timer and appears to have been
introduced as part of the process of writing the ACPI timer (and the
associated ACPI-safe workaround) in 2001; since we are dropping support
for systems with this ACPI bug, there is no need to keep that test code
either.
Summary:
Add support for building ossl(4) on powerpc64* by implementing ossl_cpuid and
other support functions for powerpc. The required assembly files for ppc were
already present in-tree.
Test Plan: The changes were tested using the in-tree tools/tools/crypto/cryptocheck.c tool on both powerpc64 and powerpc64le on a POWER9 system.
Reviewed by: #powerpc, jhibbits, jhb
Differential Revision: https://reviews.freebsd.org/D41837
Remove support for old gcc versions by unconditionally defining
__MATH_BUILTIN_RELOPS and __MATH_BUILTIN_CONSTANTS. Per kib's request,
don't #undef those so it's easier to understand what the builtins are
doing.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D45655
Sponsored by: Netflix
All supported compilers support the gcc 3 attribute extensions. Remove
the #else clauses for this. Also, latter-day pcc compilers also define
__GNUC__, so there's not need to also test for __PCC__.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D45654
Sponsored by: Netflix
All compilers that can build FreeBSD binaries (as opposed to the entire
system) support at least gcc 9 (gcc, clang, tcc). Even pcc supports most
of the gcc 4.3 attributes. Make this file simpler by removing support
for pre-3.0 compilers.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D45653
Sponsored by: Netflix
If WITH_CLOUDWARE is not set, we didn't build BASIC-CLOUDWARE; don't try
to install it into the /VM-IMAGES/ directory as part of ftp-stage.
Fixes: 4771c2e9d1 "release: Publish non-uploaded cloudware bits"
MFC after: 6 days
This release resolves 3 upstream found CVEs:
- Fixed potential use after free after SSL_free_buffers() is called (CVE-2024-4741)
- Fixed an issue where checking excessively long DSA keys or parameters may be very slow (CVE-2024-4603)
- Fixed unbounded memory growth with session handling in TLSv1.3 (CVE-2024-2511)
The old Linux used 8-bit rtm_table field of the RTM_NEWROUTE message to
specify routing table id. Modern netlink uses RTA_TABLE 32-bit attribute.
Unfortunately, there is modern software (namely bird) that would prefer
the old API as long as the routing table id fits into 8-bit.
PR: 279662
And from struct riscv_bootparams. It is no longer needed.
Reviewed by: br, markj
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45470
Currently we create the DMAP by mapping the entire range between the
smallest and largest physical memory addresses with L1 superpages. This
is obviously overkill, and we may end up mapping all kinds of ranges that
are not real memory.
In the case of the HiFive Unmatched (obsolete hardware), there is an
errata resulting in faults when a TLB mapping spans PMP (firmware)
protection regions. So, when our DMAP mapping spans into the memory
reserved by OpenSBI, we get a fatal fault. This highlights the need to
be smarter here.
Therefore, let's attempt to build the DMAP a little more correctly by
walking the physmap array and mapping each range individually. It is not
perfect in that we still only respect the range to a 2MB granularity,
but this could be improved in the future.
Reviewed by: markj
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45328
The overall goal of the change is to reduce the amount of work done in
locore assembly, and defer as much as possible until pmap_bootstrap().
Currently, half the setup is done in assembly, and then we pass the l1pt
address to pmap_bootstrap() where it is amended with other mappings.
Inspiration and understanding has been taken from amd64's
create_pagetables() routine, and I try to present the page table
construction in the same way: a linear procedure with commentary
explaining what we are doing and why. Thus the core of the new
implementation is contained in pmap_create_pagetables().
Once pmap_create_pagetables() has finished, we switch to the new
pagetable root and leave the bootstrap ones created by locore behind,
resulting in a minimal 8kB of wasted space.
Having the whole procedure in one place, in C code, allows it to be more
easily understood, while also making it more amenable to future changes
which depend on CPU feature/errata detection.
Note that with this change the size of the early devmap is bumped up
from one to four L2 pages (8MB).
Reviewed by: markj
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45327
This is useful for two reasons. Within this change, it allows the
early DTB mapping to be eliminated, as we can now just dereference the
physical address provided by FW and copy the DTB contents into KVA.
It will also aid in an upcoming change: the larger reworking of page
table bootstrapping on this platform.
Reviewed by: markj, jhb
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45324
The machinery to support 64-bit counters even on 32-bit kernels had a
bug where it would unitentionally truncate the value back to 32-bits
when transferring to a new counter. This resulted in buggy be behavior
on 64-bit kernels as well.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Separate function into assertive part and into assigning part.
Consistently use __func__ in the assertions. Write the assigning code in
a declarative style.
The functional change is that we no longer validate flags in the
non-INVARIANT kernel. The assertion that checks flags has been there for
17 years, so all code that calls with invalid flags must have been
filtered and fixed.
For invop providers (i.e., fbt and kinst) we can simply reach into the
invop trapframe to fetch argument registers for arguments 0-7; for
argument 8 and beyond we have to read the value off of the stack.
Reviewed by: Domagoj Stolfa, avg
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D45649
SDT calls dtrace_probe() directly, and this can be used to pass up to
five probe arguments directly. To pass the sixth argument (SDT
currently doesn't support more than this), we use a hack: just add
additional parameters to the call and cast dtrace_probe accordingly.
This happens to work on amd64, but doesn't work in general.
Modify SDT to call dtrace_probe() after storing arguments beyond the
first five in thread-local storage. Implement sdt_getargval() to fetch
extra argument values this way. An alternative would be to use invop
handlers instead and make sdt_probe_func point to a breakpoint
instruction, so that one can extract arguments using the breakpoint
exception trapframe, but this makes the providers more expensive when
enabled and doesn't seem justified. This approach works well unless we
want to add more than one or two more parameters to SDT probes, which
seems unlikely at present.
In particular, this fixes fetching the last argument of most ip and tcp
probes on arm64.
Reported by: rwatson
Reviewed by: Domagoj Stolfa
MFC after: 1 month
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D45648
