The __has_* macros are no longer clang-speicifc. gcc 5 introduced
__has_include, gcc 9 introduce __has_attribute, gcc 10 introduced
__has_builtin. So all of these are supported by all the versrions of gcc
we support as a project (we have gcc 10 and newer ports, but no older
ones), so just refer to them as supported by gcc. The exact version
doesn't matter so much these days (we provide a fallback for older
compilers still, should anybody still be using them), so don't mention
them in the comments (but here in the commit message they are
discoverable).
gcc 14 adds __has_feature and __has_extension, so note that since it
will be relevant for many years.
Sponsored by: Netflix
The ACLE defines the modern ARM compiler symbols. ARM published
acle-compat.h to ease the transition to the new standard. This standard
is in all modern versions of gcc and clang, only gcc prior to 4.4 lacked
them (though our 4.2.1 back-ported them, IIRC). Since this is no longer
needed, remove the global inclusion in sys/ctypes.h. We should likely
remove arm/include/acle-compat.h as well (it's unused now in the tree),
but I'll make sure this change is the NOP I think it is before moving
ahead there. I also recall at one time some out of tree code needing
this file, though the need for it to make things right has long since
past.
Sponsored by: Netflix
ispfw(4) recently gained firmware for Qlogic 27XX and 28XX
FC controllers, and isp(4) now selects the newer of firmware in
flash or in ispfw(4) to load for those controllers.
This differs from the previous behavior (which remains for older
controllers), which was to always load the ispfw(4) firmware if it
is available.
This adds a loader tunable, hint.isp.N.fwload_force to default to
loading the ispfw(4) firmware, whether or not it is newer than the
firmware in flash. This allows the user to always use the known
firmware version included with the kernel.
Note that there is an existing fwload_disable tunable that tells
the driver to always load the firmware from flash and ignore
ispfw(4). If fwload_disable is set, fwload_force will be ignored.
So users with existing fwload_disable tunables will have the same
behavior.
If a user specifies both fwload_force and fwload_disable for the
same controller, the isp(4) driver prints a warning message,
and fwload_disable will be honored.
The user can see which firmware is active through the
dev.isp.N.fw_version* sysctl variables.
share/man/man4/isp.4:
Document the new loader tunable.
sys/dev/isp/isp.c:
In isp_load_risc_flash(), changet the decision logic to
also consider ISP_CFG_FWLOAD_ONLY. Load the flash firmware
and get the version, so the user knows what it is, but if
the user set fwload_force, honor that. If the user didn't
set fwload_force, the behavior remains to select the newer
firmware version.
sys/dev/isp/isp_pci.c:
Add a new fwload_force tunable. Print out a warning if the
user sets both fwload_disable and fwload_force.
sys/dev/isp/ispvar.h:
Add a new ISP_CFG_FWLOAD_FORCE configuration bit.
Reviewed by: mav
MFC after: 1 week
Sponsored by: Spectra Logic
Differential Revision: <https://reviews.freebsd.org/D45688>
The isp(4) driver (and ispfw(4) firmware) previously only included
firmware for Qlogic controllers up to 8Gb. It recently gained
firmware for the 27XX and 28XX series controllers along with
improved firmware loading capabilities.
The 9.x firmware available for the 27XX and 28XX controllers in
ispfw(4) adds login state for NVMe devices in the top nibble of
the login state in the port database (isp_pdb_24xx_t in ispmbox.h).
This breaks the check at the end of isp_getpdb() to make sure the
device is in the right login state. As a result, it breaks device
discovery for many (perhaps all?) FC devices. In my testing with
IBM LTO-6 drives attached to a quad port 16Gb Qlogic 2714, they
don't show up when they are directly connected (and in loop mode)
or connected via a switch (and in fabric mode).
So, mask off the top bits of of the login state before checking it.
This shouldn't break anything, because all of the existing login
states defined in ispmbox.h are in the low nibble.
sys/dev/isp/ispmbox.h:
Add a FCP login state mask define, and a NVMe login state
shift.
sys/dev/isp/isp.c:
In isp_getpdb(), make sure we're only looking at the FCP
login state bits when we try to determine whether a device
is in the right login state.
MFC after: 1 week
Sponsored by: Spectra Logic
Reviewed by: mav
Differential Revision: <https://reviews.freebsd.org/D45660>
Ahead of including inline in __always_inline, move __always_inline to
where inline goes.
Reviewed by: imp, kib, olce
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D45710
Ahead of including inline in __always_inline, move __always_inline to
where inline goes.
Reviewed by: kib, olce
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D45709
Ahead of including inline in __always_inline, move __always_inline to
where inline goes.
Reviewed by: kib, olce
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D45708
Mostly copied from smbfs. This driver in its current state has the exact
same issue that prevents the generic putpages implementation from
working.
Sponsored by: https://www.patreon.com/valpackett
Reviewed by: dfr
Differential Revision: https://reviews.freebsd.org/D45639
MFC after: 3 months
Background:
If a user does pathconf(_, _PC_MIN_HOLE_SIZE) on a fusefs file system,
the kernel must actually issue a FUSE_LSEEK operation in order to
determine whether the server supports it. We cache that result, so we
only have to send FUSE_LSEEK the first time that _PC_MIN_HOLE_SIZE is
requested on any given mountpoint.
Problem 1:
Unlike fpathconf, pathconf operates on files that may not be open. But
FUSE_LSEEK requires the file to be open. As described in PR 278135,
FUSE_LSEEK cannot be sent for unopened files, causing _PC_MIN_HOLE_size
to wrongly report EINVAL. We never noticed that before because the
fusefs test suite only uses fpathconf, not pathconf. Fix this bug by
opening the file if necessary.
Problem 2:
On a completely sparse file, with no data blocks at all, FUSE_LSEEK with
SEEK_DATA would fail to ENXIO. That's correct behavior, but
fuse_vnop_pathconf wrongly interpreted that as "FUSE_LSEEK not
supported". Fix the interpretation.
PR: 278135
MFC after: 1 week
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D44618
When a lagg interface is destroyed, it destroys all of the lagg ports,
which triggers an asynchronous link state change handler. This in turn
may generate a netlink message, a portion of which requires netlink to
invoke the SIOCGIFMEDIA ioctl of the lagg interface, which involves
scanning the list of interface media. This list is not internally
locked, it requires the interface driver to provide some kind of
synchronization.
Shortly after the link state notification has been raised, the lagg
interface detaches itself from the network stack. As a part of this, it
blocks in order to wait for link state handlers to drain, but before
that it destroys the interface media list. Reverse this order of
operations so that the link state change handlers drain first, avoiding
a use-after-free that is very occasionally triggered by lagg stress
tests. This matches other ethernet drivers in the tree.
MFC after: 2 weeks
State keys are trivially const in lookup routines, so annotate them as
such. No functional change intended.
Reviewed by: kp
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Modirum
Differential Revision: https://reviews.freebsd.org/D45671
The 11th and 12th columns are the effective and real UIDs, respectively.
The 13th column is a group list whose first member is the effective
GID.
Reviewed by: arrowd
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D45700
The lib9p implementation takes a strict interpretation of the Twalk RPC
call and returns an error for attempts to lookup ".". The workaround is
to fake the lookup locally.
Reviewed by: Val Packett <val@packett.cool>
MFC after: 3 months
Use roundup_pow_of_two in place of a local function that does the same thing.
Reviewed by: alc, markj
Differential Revision: https://reviews.freebsd.org/D45536
Use roundup_pow_of_two and rounddown_pow_of_two in place of expressions.
Reviewed by: alc, markj
Differential Revision: https://reviews.freebsd.org/D45536
In two places, use the rounddown_pow_of_two macro in place of expressions.
Reviewed by: alc, markj
Differential Revision: https://reviews.freebsd.org/D45536
Linux has a header file that defines an ilog2 function and some simple
functions/macros that use it: roundup_pow_of_two, is_power_of_2,
rounddown_pow_of_two, and order_base_2. This change moves three of
those simple functions (all but is_power_of_2) from linuxkpi to
libkern. It also deletes a few implementations of these functions
that have previously been copied into code for various device drivers,
so that they can use the libkern version. The is_power_of_2 macro was
not moved because powerof2 in param.h provides almost the same service
already (except that they disagree about whether 0 is a power of two).
Since the linux definitions of these functions were copied into
FreeBSD 11 years ago, linux has improved them, and this change
provides those improvements. In particular, a giant table of log
values for evaluating ilog2 for constant values is no longer
necessary.
Reviewed by: alc, markj (previous version)
Differential Revision: https://reviews.freebsd.org/D45536
Replace is_power_of_2(length) with power2(length). When length != 0, as in
this case, they produce the same result. This will allow an implementation
of is_power_of_two to be dropped.
Reviewed by: alc, markj
Differential Revision: https://reviews.freebsd.org/D45536
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/D45695
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")