Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
Currently Makefile.libcompat queries a few MK_FOO variables to determine
what is being built. However, it is plausible (and indeed, downstream
in CheriBSD, this is the case) that these may vary between the native
and the compat architecture. In order to correctly determine their
values for the compat architecture, we need to defer their evaluation
until we are in the compat sub-make where src.opts.mk will give us the
right value for the compat MACHINE_ARCH.
Reviewed by: brooks, jhb, imp
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D40570
This is no longer referenced as of commit 724123b9f4 ("libcompat: Use
WORLDTMP sysroot").
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40569
Because fnmatch has no side effects, we can safely avoid calling fnmatch
if the end result does not matter anyway (the compiler cannot see this,
so it calls fnmatch in the event it has side-effects).
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/747
This way a possible clash between FAULT_* and KERN_* numbering is
avoided, and panics checks for fault_status confusion become more
efficient.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40771
Relevant/interesting changes:
o optimize string matching for ':M' and ':N'
o warn about malformed patterns in ':M', ':N' and '.if make(...)'
o allow guards to be targets as well as variables
The guard targets may include variable references like
__${.PARSEDIR:tA}/${.PARSEFILE}__
o optimization for makefiles protected from multiple-inclusion
skip even opening the file after first include.
o var.c: do not allow delete of readOnly variable
o parse.c: .break takes no args
As of 70ea484e3e vdev_cache has been removed. Stop reporting on it.
Without this systat reports:
sysctl(kstat.zfs.misc.vdev_cache_stats.misses...) failed:
No such file or directory
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D40742
Let node_get calculate it's own owner value. Don't pass the count
parameter, since it's always 2. Save 16 bytes in insert(). Move,
without modifying, slot and trimkey to handle use-before-declaration
problem.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40723
Presumably these warnings will be fixed upstream at some point.
contrib/libxo/xo/xo.c:99:9: error: variable 'hflag' set but not used [-Werror,-Wunused-but-set-variable]
int hflag = 0, jflag = 0, tflag = 0,
^
contrib/libxo/xo/xo.c:99:20: error: variable 'jflag' set but not used [-Werror,-Wunused-but-set-variable]
int hflag = 0, jflag = 0, tflag = 0,
^
contrib/libxo/xo/xo.c:99:31: error: variable 'tflag' set but not used [-Werror,-Wunused-but-set-variable]
int hflag = 0, jflag = 0, tflag = 0,
^
contrib/libxo/xo/xo.c💯2: error: variable 'zflag' set but not used [-Werror,-Wunused-but-set-variable]
zflag = 0, qflag = 0, star1 = 0, star2 = 0;
^
contrib/libxo/xo/xo.c💯13: error: variable 'qflag' set but not used [-Werror,-Wunused-but-set-variable]
zflag = 0, qflag = 0, star1 = 0, star2 = 0;
^
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D40668
The old one triggered a false positive -Warray-bounds from GCC (the
compiler assumed len was always 0), but it was also fragile with
manually computed lengths paired with strcat vs using a string
builder.
Differential Revision: https://reviews.freebsd.org/D40658
- Remove now unnecessary MACHINE_ARCHES definition. The default logic
in kern_mib.c works fine now for RISC-V.
- Remove custom sv_machine_arch hook from sysentvec.
Fixes: 1ca12bd927 Remove the riscv64sf architecture.
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D40648
These symlinks are broken. They point to files that don't exist, and
rely on having them be built using a 'in-tree' build that FreeBSD
doesn't use. They also show up as errors on grep -r. Since they are
broken and can't possibly work, remove them for now since non-functional
symlinks matching an upstrem repo that can't work in our repo aren't
worth the error messages.
Though one could argue the whole debian directory should be removed, I
did the minimal change necessary. These can return when the fundamental
issue is fixed and the contrib/debian tree is useful on FreeBSD systems.
This is purely a cosmetic change. vm_radix.c has lines that reach past
column 80 and this change cleans that up. The associated changes to
subr_pctrie.c are just to keep mirroring vm_radix.c.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40764
Reduces severe performance degradation due to false-sharing. Note that this
does not account for hardware which can perform adjacent cacheline prefetch.
[mjg: massaged the commit message and the patch to use aligned_alloc
instead of malloc]
PR: 272238
MFC after: 1 week
since its only reason to exist is removed.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40700
Instead of using VV_READLINK vnode flag and checking it in one place,
just assign VLNK type to the Fdesc vnodes for linrdlnk mounts. Then all
places where symlinks needs to be followed, e.g. lookup(), are handled.
PR: 272127
Reported by: Peter Eriksson <pen@lysator.liu.se>
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40700
In _lookup_ge, where a loop "looks for an available edge or val within
the current bisection node" (to quote the code comment), the value of
index has already been modified to guarantee that it is the least
value than can be found in the non-NULL child node being
examined. Therefore, if the non-NULL child is a leaf, there's no need
to compare 'index' to anything, and the value can just be returned.
The same is true for _lookup_le with 'most' replacing 'least'.
Reviewed by: alc
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D40746
By default, our ASLR implementation is supposed to cluster anonymous
memory allocations, unless the application's mmap(..., MAP_ANON, ...)
call included a non-zero address hint. Unfortunately, clustering
never occurred because kern_mmap() always replaced the given address
hint when it was zero. So, the ASLR implementation always believed
that a non-zero hint had been provided and randomized the mapping's
location in the address space. To fix this problem, I'm pushing down
the point at which we convert a hint of zero to the minimum allocatable
address from kern_mmap() to vm_map_find_min().
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40743
- Read the version from cts.protocol_version.
- Only check xport_specific.nvme for PCI-e info for XPORT_NVME.
Reviewed by: chuck, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D40618
The default xport ops for a new bus is xport_default, not NULL, so
check for that when determining if a bus failed to find a suitable
transport. In addition, the path needs to be freed with xpt_free_path
instead of a plain free so that the path's reference on the sim is
dropped; otherwise, cam_sim_free in the caller after xpt_bus_register
returns failure will hang forever.
Note that we have to exempt the xpt bus from this check as it uses
xport_default on purpose.
Reviewed by: mav, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D40617
- Replace a magic number with CTS_NVME_VALID_SPEC.
- Set the transport and protocol versions the same as for XPT_PATH_INQ.
Probably we shouldn't bother with setting the version in the 'spec'
member of ccb_trans_settings_nvme at all and use the transport
and/or protocol version field instead.
Reviewed by: chuck, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D40616
There was a mistake in the previous commit, it used the incorrect
spelling of the FIB variable name and was not functional
Also corrects an issue with the IPv6 default route variable name.
Fixes: 30659d1dcb ("Add support for adding default routes for other FIBs")
Sponsored-by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D37685
The ichsmb driver does not actually handle SMBALERT, other than by logging the
first 16 occurences of the ICH_HST_STA_SMBALERT_STS_SMBALERT status
flag. Because the SMBALERT is not acknowledged by the host, clearing it in the
host status register does not appear to work as long as some slave device is
pulling the SMBALERT line low, at least for C2000 chips. As a result, if a slave
device does pull SMBALERT low the interrupt handler will always loop its maximum
of 16 times attempting to clear all status register flags and device_printf the
status register. The result is the kernel message buffer is littered with these
device_printfs at every interrupt.
To remedy the problem, the ICH_HST_STA_SMBALERT_STS flag is zeroed in the read
host status register value, just as with ICH_HST_STA_INUSE_STS and
ICH_HST_STA_HOST_BUSY. This allows the loop to break when no other flags that
must be handled are set in the host status register. Additionally, because the
SMBALERT is not actually handled the SMBALERT logging is omitted as it has no
actual function at this time.
Reviewed by: imp
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D39966
