traceroute: MFC: graceful recover after networking errors with as_server
Currently, the traceroute[6] utility does not check
for possible networking errors while talking to as_server
in case of "traceroute -a". Meantime, there is a common case
when trace is long and it has many non-responding hops
(shown as '* * *'), so as_server aborts our connection,
hence no AS numbers shown for the rest of trace.
Somewhat artifical way to reproduce the problem:
traceroute to 57.144.244.1 (57.144.244.1), 80 hops max, 48 byte packets
5 [AS174] be2950.ccr42.fra05.atlas.cogentco.com (154.54.72.42) 74.277 ms 9.605 ms 9.599 ms
6 [AS174] 149.11.228.19 (149.11.228.19) 9.506 ms 9.466 ms 9.420 ms
7 [AS33182] po172.asw02.fra5.tfbnw.net (129.134.108.146) 9.725 ms 9.874 ms 9.696 ms
8 [AS32934] psw04.fra5.tfbnw.net (157.240.59.85) 8.718 ms 8.691 ms 8.618 ms
9 * * *
10 [AS0] edge-star-mini-shv-01-fra5.facebook.com (57.144.244.1) 9.747 ms 9.815 ms 9.699 ms
[10 lines not shown]
kern_syscall_deregister: document syscall 0 no-op logic
Document syscall #0 being handled specially in
`kern_syscall_deregister(..)`: it's a reserved syscall and not
dynamically registered, and hence does not need to be deregistered in
the function.
Co-authored-by: ngie@
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D54326
(cherry picked from commit f384784289dba13b90138a89d3df3a8ea063aff9)
kern_syscall_deregister: document syscall 0 no-op logic
Document syscall #0 being handled specially in
`kern_syscall_deregister(..)`: it's a reserved syscall and not
dynamically registered, and hence does not need to be deregistered in
the function.
Co-authored-by: ngie@
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D54326
(cherry picked from commit f384784289dba13b90138a89d3df3a8ea063aff9)
ttys: Correct comment about required statuses
The status field also accepts onifconsole and onifexists,
so it looks crusty saying that it only accepts on and off.
Reviewed by: imp
Closes: https://github.com/freebsd/freebsd-src/pull/2042
ttys: Align comment whitespace and wrapping
This doesn't lengthen or shorten any configuration,
only comments, so merging the configuration will be safe.
Reviewed by: imp
Closes: https://github.com/freebsd/freebsd-src/pull/2042
buf: Relax an assertion in BUF_UNLOCK
The BUF_UNLOCK macro asserts that B_REMFREE is not set, as it is up to
the lock owner to complete the dequeue from the free list before
releasing the lock. However, if the thread has acquired the lock
multiple times, then releasing the recursive lock should be ok. Modify
the assertion to reflect this.
This was triggered by an out-of-tree filesystem.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55418
rge: log silicon revision during attach
The initial import from OpenBSD contained chip revision printf() calls
commented out, as OpenBSD's bare printf() style does not translate to
FreeBSD's device_printf() idiom. The result is that users cannot
distinguish RTL8125 from RTL8125B, RTL8125D_1, RTL8125D_2 etc. via
dmesg alone, even though all variants show as '<RTL8125>' from the PCI
probe string.
Add proper device_printf() calls including the raw hwrev value,
consistent with how re(4) reports chip revisions.
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Reviewed by: zlei, imp, adrian
Differential Revision: https://reviews.freebsd.org/D55402
rge: correctly free busdma memory / zero things out only if allocated
* Only free busdma memory that was allocated
* Don't free tx/rx rings until their buffers have also been freed
PR: kern/293307
Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D55420
rge: fix callout setup/teardown; handle invalid ethernet address
* Do the callout init early; since some of the teardown path expects
the callout to be valid
* Handle an invalid ethernet address by generating a local one.
PR: kern/293307
Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D55419
OFW: Improve OFW_CPU.
Accept the assigned clock on the CPU node.
Don't report a missing "clock-frequency" property if the CPU node has
a "clocks" property.
MFC after: 3 weeks
fusefs: remove the obsolete rename_lock
This lock was included in the original GSoC submission. Its purpose
seems to have been to prevent concurrent FUSE_RENAME operations for the
current mountpoint, as well as to synchronize FUSE_RENAME with
fuse_vnode_setparent. But it's obsolete, now that ef6ea91593e added
mnt_renamelock .
MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D55231
