nfs_commonkrpc.c: Handle NFSERR_DELAY for Sequence correctly
Unlike RFC5661 (the original NFSv4.1 RFC), RFC8881 specifies
that a NFS4ERR_DELAY reply to the SEQUENCE operation requires
a reply using the same slot/sequence#.
This patch fixes handling of this case, so it conforms to
RFC8881.
(cherry picked from commit 6901cbbd5a2c00d378a7f87426b36d6ee6ce0aa2)
nfs_commonkrpc.c: Handle NFSERR_DELAY for Sequence correctly
Unlike RFC5661 (the original NFSv4.1 RFC), RFC8881 specifies
that a NFS4ERR_DELAY reply to the SEQUENCE operation requires
a reply using the same slot/sequence#.
This patch fixes handling of this case, so it conforms to
RFC8881.
(cherry picked from commit 6901cbbd5a2c00d378a7f87426b36d6ee6ce0aa2)
aq(4): interface lifecycle and link-state fixes
aq_if_init() programmed the address captured at attach, so an address set
with "ifconfig ether" or by lagg(4) enslavement was never written to
unicast filter slot 0: the interface transmitted with the new address but
the MAC still filtered on the old one, so it received nothing. Copy the
current if_getlladdr() the way the other iflib drivers do.
The link state could latch UP forever. aq_if_stop() cleared linkup
before calling aq_if_update_admin_status(), which suppressed the
LINK_STATE_DOWN transition the "link was UP" branch would have made.
Announce the down transition directly from aq_if_stop() instead, and do
not poll the admin status there at all: the MAC has just been reset, so a
stale link reading would re-announce the link as up.
The admin task itself had to stop reporting a link on a stopped
interface. iflib runs it while either IFF_DRV_RUNNING or IFF_DRV_OACTIVE
is set, and iflib_stop() sets OACTIVE, so the task kept polling after the
stop and re-announced LINK_STATE_UP behind the driver's back. Treat a
[22 lines not shown]
aq(4): mailbox, flow-control and firmware error-handling fixes
Fold the whole-driver-review correctness and hardening fixes for the
firmware and hardware layers.
Advance the firmware-mailbox address per word in aq_hw_fw_downld_dwords():
on B1 silicon each loop iteration waits for the mailbox address register
to differ from the expected address, but it was set once and never moved,
so after the first word every wait returned immediately and read stale
data. Advance it four bytes per word. B0 is unaffected (it polls the
busy bit). The same function also left err set to ETIMEDOUT after
successfully force-recovering the RAM CPU semaphore; the transfer loop is
guarded by "--cnt && !err", so it ran zero iterations and returned a
timeout with an untouched buffer, making the recovery path dead code.
aq_hw_get_mac_permanent() ignored the get_mac_addr() error and then
examined a buffer the firmware op never wrote on failure. A fresh softc
is zero, so the "invalid address" test fired, a random locally
administered MAC was substituted, and err was overwritten with 0 -- a
[46 lines not shown]
aq(4): clean up diagnostics and remove dead code
Non-functional cleanup, no change in behavior.
device_printf() already prefixes each line with the device name, so the
inline "atlantic:" token in the status and error messages produced a
doubled prefix and diverged from the trace macros; remove it so all
output carries one uniform "aqN:" prefix. Compile the RX/TX descriptor
tracers only when AQ_CFG_DEBUG_LVL > 2 and make them no-op macros
otherwise, so the default build no longer pays a cross-TU call plus
argument evaluation per descriptor.
Drop enum aq_dev_state, struct aq_rx_filters, and struct aq_vlan_tag,
which have no remaining references now that VLAN state lives in a
bitstr_t. Replace the four identical aq_sysctl_print_{tx,rx}_{head,tail}
handlers, each carrying a dead write path on a read-only oid, with one
aq_sysctl_print_ring_ptr that selects the accessor from arg2. Reduce the
thermal and PHY-recovery comments to single terse lines that keep the
load-bearing register numbers and the A1-vs-A2 recovery difference.
[5 lines not shown]
aq(4): PHY thermal-shutdown handling and correctness fixes
Fold the thermal-protection work and the correctness fixes that landed
alongside it.
Report and auto-recover from PHY thermal shutdown. The Atlantic PHYs can
autonomously shut down on over-temperature, latching global fault 0x8007
and dropping the link; Atlantic 2 ships this armed, Atlantic 1 disabled.
Arm it on Atlantic 1 at interface init (1E.C478.A via the MAC's MDIO
controller), and recover from a trip automatically: the admin-status poll
detects the fault, logs the shutdown limit and measured temperature, and
holds the link down until the PHY cools, then restores it -- Atlantic 1
needs a PHY reset (1E.2681.0) with the MAC firmware running plus a full
re-init, Atlantic 2 recovers on the re-init alone. New firmware ops
get_phy_fault, phy_reset, thermal_arm, and get_thermal_limit back the
state machine in aq_if_update_admin_status().
Make that Atlantic 1 thermal MDIO path address-correct and fail-safe.
The direct-MDIO helpers hardcoded the Clause-45 port address to 0, but it
[29 lines not shown]
aq(4): observability controls and sysctl/header hygiene
Fold the driver's observability and infrastructure work.
Make aq_device.h self-contained: it declares struct aq_dev in terms of
iflib, bitstring, socket, and ethernet types but included none of the
headers that define them, compiling only because every includer happened
to pull those first. Include what it uses. No functional change.
Make the debug controls per-instance. The debug and debug_categories
sysctls were registered per device but pointed at file-scope globals, so
writing dev.aq.1.debug also changed dev.aq.0.debug and a card could not
be traced in isolation. Move the level and category mask into struct
aq_dev, reach them through the aq_dev back-pointer in struct aq_hw (wired
up in attach_pre before the first firmware trace and guarded against a
NULL deref), emit through device_printf() so each line carries its unit,
and seed initial values from per-unit device hints so attach can be
traced.
[27 lines not shown]
stat.2: enhance the description of st_blocks
Reviewed by: emaste, mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D58592
cp: Correct description of SIGINFO
The manual page claimed that SIGINFO caused information to be printed to
stdout, when in fact it is printed to stderr, as one would expect. This
has been true ever since the feature was first added in 2003.
MFC after: 1 week
Fixes: 00d321a2b395 ("Add a SIGINFO handler.")
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D58392
(cherry picked from commit 5dc400ff452b0259f0c50474255ebe6e5e02edb9)
cp: Correct description of SIGINFO
The manual page claimed that SIGINFO caused information to be printed to
stdout, when in fact it is printed to stderr, as one would expect. This
has been true ever since the feature was first added in 2003.
MFC after: 1 week
Fixes: 00d321a2b395 ("Add a SIGINFO handler.")
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D58392
(cherry picked from commit 5dc400ff452b0259f0c50474255ebe6e5e02edb9)
libfetch: Fix handling of connection failures
After commit 848f360c8f9a, if one tries to connect to a closed port,
fetch reports "Operation now in progress", which is rather confusing.
Return a more useful error message, restoring the old behaviour.
Fixes: 848f360c8f9a ("libfetch: Apply timeout to connection attempts")
Reviewed by: des
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58481
(cherry picked from commit b02e02958dad2d5ce3675cbc18b9a94635d09e66)
libfetch: Further improve connection polling
* Reorganize the connection loop to make it a little more readable
* Start the timeout clock earlier
* Correctly calculate the poll timeout before calling poll()
* Don't leak the socket on failure
Fixes: 848f360c8f9a ("libfetch: Apply timeout to connection attempts")
Fixes: b02e02958dad ("libfetch: Fix handling of connection failures")
MFC after: 3 days
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58512
(cherry picked from commit 351ed134887fe5b8da39d22fcb267c96ab009ca2)
libfetch: Fix handling of connection failures
After commit 848f360c8f9a, if one tries to connect to a closed port,
fetch reports "Operation now in progress", which is rather confusing.
Return a more useful error message, restoring the old behaviour.
Fixes: 848f360c8f9a ("libfetch: Apply timeout to connection attempts")
Reviewed by: des
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58481
(cherry picked from commit b02e02958dad2d5ce3675cbc18b9a94635d09e66)
libfetch: Further improve connection polling
* Reorganize the connection loop to make it a little more readable
* Start the timeout clock earlier
* Correctly calculate the poll timeout before calling poll()
* Don't leak the socket on failure
Fixes: 848f360c8f9a ("libfetch: Apply timeout to connection attempts")
Fixes: b02e02958dad ("libfetch: Fix handling of connection failures")
MFC after: 3 days
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58512
(cherry picked from commit 351ed134887fe5b8da39d22fcb267c96ab009ca2)
if_vxlan(4): Fix panic by validating unused drvspec values
Add validation for unused parameter values in the gap between
VXLAN_PARAM_WITH_LOCAL_ADDR4 and VXLAN_PARAM_WITH_LOCAL_ADDR6 to prevent
panics.
PR: 297151
Reported by: Robert Morris <rtm at lcs.mit.edu>
Reviewed by: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58552
(cherry picked from commit c4d7745cd90fc99af3cbccfda7e11798ea7d187b)
nullfs: close a race when syncing inotify flags from the lower vnode
After a bypassed VOP, nullfs mirrors the lower vnode's inotify state
onto the upper vnode. The flags were checked with lockless reads
before being updated with the asserting flag set/unset primitives, so
two threads syncing the same vnode concurrently (or a sync racing a
watch being established) could both decide to make the same change;
the loser then trips the "flags already set" assertion on an
INVARIANTS kernel. On other kernels the race is harmless.
Keep the lockless check as the fast path, but re-make the decision
under the vnode interlock before actually changing the flags.
Reproduced in a 4-CPU VM with one thread cycling an inotify watch on
a lower-filesystem file while several threads stat(2) the same file
through a nullfs mount: the unpatched INVARIANTS kernel panics under
this load, the patched kernel runs it to completion.
Fixes: f1f230439fa4 ("vfs: Initial revision of inotify")
[6 lines not shown]
libc: Add strfromd, strfromf, and strfroml per C23
strfromd(), strfromf(), and strfroml() are implemented directly
in terms of gdtoa. If a non-conforming format string is passed,
the string "EDOOFUS" is returned and errno set to EDOOFUS as an
extension.
Reviewed by: fuz
MFC after: 1 month
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2301
Signed-off-by: Faraz Vahedi <kfv at kfv.io>
msun: add asinpi, acospi, and atanpi
This commit implements the inverse half-cycle
trigonometric functions:
asinpi(x) = asin(x) / pi Eq. (1)
acospi(x) = acos(x) / pi
atanpi(x) = atan(x) / pi
Implemention details are contained in src/s_asinpi.c and
src/a_atanpi.c, where the details for acospi(x) appear in
the former.
*************
CAVEAT EMPTOR: The ld128 code has been only compiled. It has
not been tested for correctness due to lack of hardware.
*************
[125 lines not shown]
libc/merge.c: use memcpy() for copying
Currently mergesort() uses ICOPY_*() to copy data as four byte blocks
instead of one byte. However, this is only achievable when both size and
base arguments are aligned to four bytes.
Use of memcpy() is ideal as 1) it is cleaner and 2) the library will use
SIMD for copying when the hardware supports it. Compared to ICOPY_*(),
SIMD can support up to 64 bytes. When the SIMD-backed memcpy() find the
address is unaligned, it can first copy data up to the nearest aligned
address, and then use SIMD operations for faster transfer. Thus memcpy()
can give better performance than mergesort()'s own implementation.
This is benchmarked on amd64 where there isn't a SIMD-backed
implementation yet. However, the baseline implementation in assembly
already delivers better performance in unaligned cases although there is
some performance drops in aligned cases. The benchmark results and
script is available in the Phabricator review. Ideally, more performance
improvements will come when amd64 gets SIMD implementation of memcpy().
[5 lines not shown]