When a physical disk(PD) [belonging to a RAID1 Virtual disk(VD)] is
removed, driver may still use the reference to the removed PD while submitting
IO to the controller. Controller firmware faults upon receipt of such IO.
This patch fixes this issue by not using any reference to the removed PD.
Reviewed by: imp
Approved by: imp
Sponsored by: Broadcom Inc
Differential Revision: https://reviews.freebsd.org/D44282
The old timezone(3) function has long since been obsolete and has a
fatally flawed interface. Retain this function for compatibility
purposes, but shift to providing the offset from UTC in the timezone
variable, whether or not the timezone observes summer time in the
'daylight' variable. Document the tzname variable that's already been
set. Also make _tztab() static. It's not used in libc (or anywhere in
the tree) and it's not exported as a public dynamic symbol.
Sponsored by: Netflix
Reviewed by: brooks, kib
Differential Revision: https://reviews.freebsd.org/D44281
If we are able to open /sys/firmware/fdt, but aren't able to read it,
fall back to /proc/device-tree. Remove comment that's not really true,
it turns out.
Sponsored by: Netflix
If we can read the UEFI memory map, go ahead and print the memory map.
While the kernel prints this with bootverbose, having it at this stage
is useful for debugging other problems.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44287
The host_* syscalls are all raw Linux system calls, not the POSIX
wrappers that glibc / musl create. So we have to ranage change the
return value of host_llseek correctly to use the negative value hack
that all Linux system calls use.
This fixes a false positive error detection when we do something like
lseek(fd, 0xf1234567, ...); This returns 0xf1234567, which is a negative
value which used to trigger the error path. Instead, we check using the
is_linux_error() and store the return value in a long. Translate that
errno to a host errno and set the global errno to that and return
-1. lseek can't otherwise return a negative number, since it's the
offset after seeking into the file, which by definition is positive.
This kept the 'read the UEFI memory map out of physical memory' from
working on aarch64 (whose boot loader falls back to reading it since
there are restrictive kernel options that can also prevent it), since
the physical address the memory map was at on my platform was like
0xfa008018.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44286
offset is signed. Copy it to the unsigned res before shifting. This
avoids any possible undefined behavior for right shifting signed
numbers. No functional change intended (and the code generated is the
nearly same for aarch64).
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44285
Linux has the convention of returning -ERRNO to flag errors from its
system calls. Sometimes other negative values are returned that are
success... However, only values -1 to -4096 (inclusive) are really
errors. The rest are either truncated values that only look negative (so
use long instead of int), or are things like addresses or legal unsigned
file offsets or similar that are successful returns. Filter out the
latter.
Sponsored by: Netflix
Although these particular constants aren't supported, the incorrect
values break bird 2.15 operation.
PR: 277618
Reported by: Ondrej Zajicek <santiago@crfreenet.org>
All callers do it right. Don't be overprotective against a stupid
caller and thus don't look like a code that leaks a resource.
Reported by: Coverity Scan
CID: 1539210
This brings the rack stack up to the current level used at NF. Many fixes
and improvements have been added. I also add in a fix to BBR to deal with
the changes that have been in hpts for a while i.e. only one call no matter
if mbuf queue or tcp_output.
Note there is a new file that I can't figure out how to get in rack_pcm.c
It basically does little except BBlogs and is a placemark for future work on
doing path capacity measurements.
Reviewed by: tuexen, glebius
Sponsored by: Netflix Inc.
Differential Revision:https://reviews.freebsd.org/D43986
Since non-doomed unionfs vnodes always share their primary lock with
either the lower or upper vnode, any forwarded call to the base FS
which transiently drops that upper or lower vnode lock may result in
the unionfs vnode becoming completely unlocked during that transient
window. The unionfs vnode may then become doomed by a concurrent
forced unmount, which can lead to either or both of the following:
--Complete loss of the unionfs lock: in the process of being
doomed, the unionfs vnode switches back to the default vnode lock,
so even if the base FS VOP reacquires the upper/lower vnode lock,
that no longer translates into the unionfs vnode being relocked.
This will then violate that caller's locking assumptions as well
as various assertions that are enabled with DEBUG_VFS_LOCKS.
--Complete less of reference on the upper/lower vnode: the caller
normally holds a reference on the unionfs vnode, while the unionfs
vnode in turn holds references on the upper/lower vnodes. But in
the course of being doomed, the unionfs vnode will drop the latter
set of references, which can effectively lead to the base FS VOP
executing with no references at all on its vnode, violating the
assumption that vnodes can't be recycled during these calls and
(if lucky) violating various assertions in the base FS.
Fix this by adding two new functions, unionfs_forward_vop_start_pair()
and unionfs_forward_vop_finish_pair(), which are intended to bookend
any forwarded VOP which may transiently unlock the relevant vnode(s).
These functions are currently only applied to VOPs that modify file
state (and require vnode reference and lock state to be identical at
call entry and exit), as the common reason for transiently dropping
locks is to update filesystem metadata.
Reviewed by: olce
Tested by: pho
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D44076
When calling VOP_CREATE(), uipc_bindat() reuses the componentname
object from the preceding lookup operation, which is likely to specify
LK_SHARED. Furthermore, the VOP_CREATE() interface technically only
requires the newly-created vnode to be returned with a shared lock.
However, the socket layer requires the new vnode to be locked exclusive
and asserts to that effect.
In most cases, this is not a practical concern because most if not
all base-layer filesystems (certainly FFS, ZFS, and msdosfs at least)
always return the vnode locked exclusive regardless of the lock flags.
However, it is an issue for unionfs which uses cn_lkflags to determine
how the new unionfs wrapper vnode should be locked. While it would
be easy enough to work around this issue within unionfs itself, it
seems better for the socket layer to be explicit about its locking
requirements when issuing VOP_CREATE().
Reviewed by: kib, olce
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D44047
It's a bit strange to require the caller to pass contrived lock flags
if the corresponding vnode is NULL, simply to appease the assertion
that exactly one of LK_SHARED or LK_EXCLUSIVE must be set. On the
other hand, we still want to catch cases in which completely bogus
or corrupt flags are passed even if the corresponding vnode is NULL.
Therefore, specifically allow empty flags for lkflags1/lkflags2 iff
the respective vp1/vp2 param is NULL.
Reviewed by: kib, olce
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D44046
crunchgen generates a foo.lo for each binary it will end up crunching
into the final product. While they have a dependency on the libs that
are used to link them, nothing will force relinking if the set of libs
needed to link them is changed. Because of this, incremental builds may
not be possible if one builds a version of, e.g., rescue/ with a broken
set of libs specified for a project -- a subsequent fix won't be rolled
in cleanly, it will require purging the rescue/ objdir.
This is a bit crude, but the foo.mk we generate doesn't actually get
regenerated all that often in practice, so a spurious relink for the
vast majority of crunched objects won't actually happen all that often.
Reviewed by: bapt, emaste, imp
Differential Revision: https://reviews.freebsd.org/D43869
I removed lib/libsys/{aarch64,arm,riscv}/syscall.S in favor of an
idential generated version. We need to clean out the .ddepend files to
ensure the generated version is actually generated.
The guard here is technically too strict, but should be fine in practice
and I've verified both the breakage and fix on an armv7 build.
Reported by: imp
Fixes: e6ffc7669a Remove pointless MD syscall(2)
Fixes: 0ee0ae2373 Remove pointless MD syscall(2)
Fixes: 7b3836c281 Remove pointless MD syscall(2)
Trying to probe+attach the child device at the point it is added comes
before the syscon handle is set up (if relevant). It will therefore be
unavailable to the attach method which is expecting it, and the first
attempt to attach the device will fail.
Just rely on the call to bus_generic_attach() at the end of the function
to perform probe+attach of dev's children.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44268
If the call to clknode_get_freq() returns an error (unlikely), report
this, rather than printing the error code as the clock frequency.
If the clock has no parent (e.g. a fixed reference clock), print "none"
rather than "(NULL)(-1)". This is a more human-legible presentation of the
same information.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44267
We may attach several of these devices, but there is no meaningful
information added to dmesg. For example:
ofwbus0: <Open Firmware Device Tree>
clk_fixed0: <Fixed clock> on ofwbus0
clk_fixed1: <Fixed clock> on ofwbus0
clk_fixed2: <Fixed clock> on ofwbus0
clk_fixed3: <Fixed clock> on ofwbus0
clk_fixed4: <Fixed clock> on ofwbus0
clk_fixed5: <Fixed clock> on ofwbus0
clk_fixed6: <Fixed clock> on ofwbus0
clk_fixed7: <Fixed clock> on ofwbus0
clk_fixed8: <Fixed clock> on ofwbus0
clk_fixed9: <Fixed clock> on ofwbus0
clk_fixed10: <Fixed clock> on ofwbus0
clk_fixed11: <Fixed clock> on ofwbus0
To reduce this noise, quiet the devices for by default. For verbose
boot, the message will be emitted.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44266
This is standard practice for clock drivers that register clocks
dynamically. Nothing else uses the CLK_DEBUG macro.
The result is that the name and frequency of the fixed clock is printed
for a verbose boot, which may aid in debugging.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44265
The msi address contains apic id. The code in vmbus_pcib_map_msi()
treats it as cpu id, which could cause mis-configuration of msix
IRQs, leading to missing interrupts for SRIOV devices. This happens
when apic id is not the same as cpu id on certain large VM sizes
with multiple numa domains in Azure. Fix this issue by correctly
mapping apic ids to cpu ids.
On vPCI version before 1.4, it only supports up to 64 vcpus
for msi/msix interrupt. This change also adds a check and returns
error if the vcpu_id is greater than 63.
Reported by: NetApp
Tested by: whu
MFC after: 1 week
When doing mbuf queueing, the packet filter hooks in ether_demux(),
ip_input(), and ip6_input() are by-passed. This means that the packet
filters don't process incoming packets, which might result in
connection failures. For example bypassing the TCP sequence number
validation will result in dropping valid packets.
Please note that this patch is only disabling mbuf queueing, not LRO.
Reported by: Herbert J. Skuhra
Reviewed by: glebius, rrs, rscheff
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D43769
I'd forgotten that we have to adjust the stderr tests from
upstream. Remove the OK files. Also remove system-status.*. These
restore the fixes I made in 517e52b6c2 which were lost when I imported
the last version of awk.
Also, force LANG to be C.UTF-8 when testing to ensure that stray lang
settings don't fail tests.
Sponsored by: Netflix
These symbols aren't present on i386 so don't try to expose them.
Given the structure of quad/Makefile.inc, it might make more sense to
have per-arch symbol maps here, but this is sufficent to build with
WITHOUT_UNDEFINED_VERSION on i386.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44243
It's unclear to me that any of these symbols ever existed. The ones
I've spot checked are only mentioned in the initial Citrus iconv import
(commit ad30f8e79b) and this code hasn't changed much over time.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D44183
The firmware lacks support for manually setting 1G and 10G baseT speeds.
However, the driver can enable auto speed masks to achieve automatic configuration
at these speeds.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42960
This update enables the display of pluggable module information
to users via the ifconfig utility.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42958
The newly added port extended hardware statistics are now accessible to
users through the sysctl interface. Also, Few obsolete stats are removed
and few stats are renamed.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42957
Increasing the maximum configurable MTU from 9000 to 9600 to
align with the firmware's capability of handling an MTU up to 9600.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42954
Enabled User Configuration of 1G Speed on Wh+ SFP28 Port with AOC
cable.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42953
The 1G speed on DAC medium is incorrectly labeled as 1000baseT, it
should be 1000baseCX. Updated the label accordingly.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D42952
