In numeric mode, the default route is printed as "default" rather
than 0.0.0.0/0 or ::/0
From the man page:
"-n: Show network addresses and ports as numbers.
Normally netstat attempts to resolve addresses and ports, and display
them symbolically. If the -n option is specified, the address is
printed numerically, according to the address family.
For more information regarding the Internet IPv4 ``dot format'', refer
to inet(3). Unspecified, or `wildcard'', addresses and ports appear
as `*''."
Reported By: rgrimes
Reviewed by: emaste, ngie, eadler, seanc
Relnotes: yes
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D10320
The KASSERT in chn_sleep() can be triggered if more than one thread
wants to sleep on a given channel at the same time. While this is not
really a common scenario, tools such as stress2, which use fork() and
the child process(es) inherit the parent's FDs as a result, we can end
up triggering such scenarios.
Fix this by removing CHN_F_SLEEPING altogether, which is not very useful
in the first place:
- CHN_BROADCAST() checks cv_waiters already, so there is no need to
check CHN_F_SLEEPING as well.
- We can check whether cv_waiters is 0 in pcm_killchans(), instead of
whether CHN_F_SLEEPING is not set.
Reported by: dougm, pho (stress2)
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47559
Since SD_F_REGISTERED is cleared at the same time SD_F_DETACHING and
SD_F_DYING are set, and since PCM_DETACHING() is always used in
conjuction with PCM_REGISTERED()/DSP_REGISTERED(), it is enough to just
check SD_F_REGISTERED.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47463
This patch fixes multiple different panic scenarios occuring during
hot-unload:
1. The channel is unlocked in chn_read()/chn_write() for uiomove(9) and
in the meantime we enter pcm_killchans() and free it. By the time we
have returned from userland and try to lock it back, the channel will
have been freed.
2. The parent channel has been freed in pcm_killchans(), but at the same
time, some yet-unstopped vchan's chn_read()/chn_write() calls
chn_start(), which eventually calls vchan_trigger(), which references
the freed parent.
3. PCM_WAIT() panics because it references a freed PCM lock.
For scenarios 1 and 2, refactor pcm_killchans() to first make sure all
channels have been stopped, and then proceed to free them one by one, as
opposed to freeing the first free channel until all channels have been
freed. This change makes the code more robust, but might introduce some
performance overhead when many channels are allocated, since we
continuously loop through the channel list until all of them are
stopped, and then we loop one last time to free them.
For scenario 3, restructure the code so that we can use destroy_dev(9)
instead of destroy_dev_sched(9) in dsp_destroy_dev(). Because
destroy_dev(9) blocks until all references to the device have went away,
we ensure that the PCM cv and lock will be freed safely.
While here, move the delete_unrhdr(9) calls to pcm_killchans() and
re-order some lines.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47462
Consider the following scenario:
1. CHN currently has its trigger set to PCMTRIG_STOP.
2. Thread A locks CHN, calls CHANNEL_TRIGGER(PCMTRIG_START), sets the
trigger to PCMTRIG_START and unlocks.
3. Thread B picks up the lock, calls CHANNEL_TRIGGER(PCMTRIG_ABORT) and
returns a non-zero value, so it returns from chn_trigger() as well.
4. Thread A picks up the lock and adds CHN to the list, which is
_wrong_, because the last call to CHANNEL_TRIGGER() was with
PCMTRIG_ABORT, meaning the channel is stopped, yet we are adding it
to the list and marking it as started.
Another problematic scenario:
1. Thread A locks CHN, sets the trigger to PCMTRIG_ABORT, and unlocks
CHN. It then locks PCM and _removes_ CHN from the list.
2. In the meantime, since thread A unlocked CHN, thread B has locked it,
set the trigger to PCMTRIG_START, unlocked it, and is now blocking on
PCM held by thread A.
3. At the same time, thread C locks CHN, sets the trigger back to
PCMTRIG_ABORT, unlocks CHN, and is also blocking on PCM. However,
once thread A unlocks PCM, because thread C is higher-priority than
thread B, it picks up the PCM lock instead of thread B, and because
CHN is already removed from the list, and thread B hasn't added it
back yet, we take a page fault in CHN_REMOVE() by trying to remove a
non-existent element.
To fix the former scenario, set the channel trigger before the call to
CHANNEL_TRIGGER() (could also come after, doesn't really matter) and
check if anything changed one we lock CHN back.
To fix the latter scenario, use the SAFE variants of CHN_INSERT_HEAD()
and CHN_REMOVE(). A similar scenario can occur in vchan_trigger(), so do
the trigger setting after we've locked the parent channel.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47461
Use callout_init_mtx(9) to associate the callback with the driver's
lock. Also make sure the callout is stopped properly during detach.
While here, introduce a dummy_active() function to know when it's
appropriate to stop or not reschedule the callout.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47459
If a fragmented IPv6 packet hits a route-to rule we have to first prevent
the pf_test(PF_OUT) check in pf_route6() from refragmenting (and calling
ip6_output()/ip6_forward()). We then have to refragment in pf_route6() and
transmit the packets on the route-to interface.
Split pf_refragment6() into two parts, the first to perform the refragmentation,
the second to call ip6_output()/ip6_forward() and call the former from
pf_route6().
Add a test case for route-to-ing fragmented IPv6 packets to verify this works
as expected.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47684
D37419 corrupts VFP context store on signal delivery and D38696 corrupts PCB
because it performs a binary copy between structures with different layouts.
Revert the problematic parts of these commits to have signals delivery
working. Unfortunately, there are more problems with these revisions and
more fixes need to be developed.
Fixes: 6926e2699a
Fixes: 4d2427f2c4
MFC after: 4 weeks
The current quirk is designed to discard duplicated data read from
the chip. Problem is, it also discards real events when they happen
to be identical, which is the case with scroll wheel events;
differently from X/Y they always move by fixed offset. This results
in two-finger scroll that would stop mid-way that could be fixed by
manually setting dev.hms.0.drift_thresh to 0.
To fix that, don't discard duplicates when there's wheel movement.
For users with actual duplicates problem this will result in scroll
suddenly becoming quite inertial, but it will stop moving at any touch,
so shouldn't be terrible.
PR: kern/276709
Reviewed By: wulf
Differential Revision: https://reviews.freebsd.org/D47640
It's possible to take a signal after pselect/ppoll have set their return
value, but before we actually return to userland. This results in
taking a signal without reflecting it in the return value, which weakens
the guarantees provided by these functions.
Switch both to restore the signal mask before we would deliver signals
on return to userland. If a signal was received after the wait was
over, then we'll just have the signal queued up for the next time it
comes unblocked. The modified signal mask is retained if we were
interrupted so that ast() actually handles the signal, at which point
the signal mask is restored.
des@ has a test case demonstrating the issue in D47738 which will
follow.
Note for MFC: TDA_PSELECT is a KBI break, we should just inline
ast_sigsuspend() in pselect/ppoll for stable branches. It's not exactly
the same, but it will be close enough.
Reported by: des
Reviewed by: des (earlier version), kib
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D47741
It may be the case that we want to avoid delivering signals that are
normally blocked by the thread's signal mask, in which case the syscall
should schedule this one instead to restore the mask prior to delivery.
This will be used by pselect/ppoll to avoid delivering signals that were
supposed to be blocked after the timeout has elapsed. The name was
chosen as this is the expected behavior of pselect/ppoll, while late
restoration of the mask is exceptional behavior for these specific
calls.
__FreeBSD_version bump as later TDA_* values have changed, third-party
modules that may be using MOD3/MOD4 need to be rebuilt.
Reviewed by: kib
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D47741
Segment base registers are at 8-byte intervals, while the register
write helper takes a byte-aligned offset. This fixes
DEV_TAB_HARDWARE_ERROR events and associated peripheral I/O failures
on an Epyc-based system with 8-segment device tables.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47752
The livedumper triggers reports from both of these sanitizers since it
necessarily accesses uninitialized or freed memory. Add a flag to
silence reports from both sanitizers.
Reviewed by: mhorne, khng
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47714
The T-HEAD custom PTE bits are defined in such a way that the
default/normal memory type is non-zero value. This _unthoughtful_ choice
means that, unlike the Svpbmt and non-Svpbmt cases, this field cannot be
left bare in our bootstrap PTEs, or the hardware will fail to proceed
far enough in boot (cache strangeness). On the other hand, we cannot
unconditionally apply the PTE_THEAD_MA_NONE attributes, as this is not
compatible with spec-compliant RISC-V hardware, and will result in a
fatal exception.
Therefore, in order to handle this errata, we are forced to perform a
check of the CPU type at the first moment possible. Do so, and fix up
the PTEs with the correct memory attribute bits in the T-HEAD case.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47458
Switch the boot argument registers to the unused s3 and s4. This ensures
the values will not be clobbered by SBI or function calls; they are
consumed late in the assembly routine.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47457
T-HEAD CPUs provide a spec-violating implementation of page-based memory
types, using PTE bits [63:59]. Add basic support for this "errata",
referred to in some places as an "extension".
Note that this change is not enough on its own, but a workaround is
needed for the bootstrap (locore) page tables as well.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45472
This is the first major quirk we need to support in order to run on
current T-HEAD/XuanTie CPUs, e.g. the C906 or C910, found in several
existing RISC-V SBCs. With these custom dcache routines installed,
busdma can reliably communicate with devices which are not coherent
w.r.t. the CPU's data caches.
This patch introduces the first quirk/errata handling functions to
identcpu.c, and thus is forced to make some decisions about how this
code is structured. It will be amended with the changes that follow in
the series, yet I feel the final result is (unavoidably) somewhat
clumsy. I expect the CPU identification code will continue to evolve as
more CPUs and their quirks are eventually supported.
Discussed with: jrtc27
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47455
Cache management operations were, for a long time, unspecified by the
RISC-V ISA, and thus these functions have been no-ops. To cope, hardware
with non-coherent I/O has implemented custom cache flush mechanisms,
either in the form of custom instructions or special device registers.
Additionally, the RISC-V CMO extension is ratified and these official
instructions will start to show up in hardware eventually. Therefore, a
method is needed to select the dcache management routines at runtime.
Add a simple set of function hooks, as well as a routine to install them
and specify the minimum dcache line size. The first consumer will be the
non-standard cache management instructions for T-HEAD CPUs.
The unused I-cache variables and macros are removed.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47454
Properly initialize setdf variable in ipsec_encap().
It is used for AF_INET6 case when IPv6 datagram is going to be
encapsulated into IPv4 datagram.
PR: 282535
Fixes: 4046178557
MFC after: 1 week
The OpenBSD derived dc program has been removed in commit 8ea6c11540,
but the creation of a directory for tests of this program had not been
disabled in that commit.
Reported by: kevans
instead of constructing transient pte itself. This pre-set PG_A and
PG_M bits, avoiding atomic pte update on access and modification. Also
it set the nx bit, the mapping is not supposed to be used for executing.
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D47717
Pass the to-be-freed page to vm_page_iter_free as a parameter, rather
than computing it from the iterator parameter, to improve performance.
Sort declarations of page_iter functions in vm_page.h.
Reviewed by: alc
Differential Revision: https://reviews.freebsd.org/D47727
In 2020, an improved implementation of the bc and dc commands
developed by Gavin D. Howard has been imported into FreeBSD.
It has replaced the OpenBSD-derived versions of these commands
in all currently supported FreeBSD releases.
The OpenBSD versions could still be built using the WITHOUT_GH_BC
option. There have been no reports of problems or unexpected
deviations from the OpenBSD version for some time, therefore
keeping the OpenBSD version is no longer required in FreeBSD.
This commit removes the option to build the OpenBSD version and
corresponding source files from -CURRENT. No MFC is planned, all
currently released FreeBSD versions should retain the build option.
The WITHOUT_GH_BC option is no longer accepted and will cause
make buildworld to fail.
Reviewed by: des, emaste
Approved by: des
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D46876
Without this patch, an all upper case user domain name
(as specified by nfsuserd(8)) would not work.
I believe this was done so that Kerberos realms were
not confused with user domains.
Now, RFC8881 specifies that the user domain name is a
DNS name. As such, all upper case names should work.
This patch fixes this case so that it works. The custom
comparison function is no longer needed.
PR: 282620
Tested by: jmmv
MFC after: 2 weeks
Notable upstream pull request merges:
#16643 -multiple Change rangelock handling in FreeBSD's zfs_getpages()
#1669746c4f2ce0 dsl_dataset: put IO-inducing frees on the pool deadlist
#16740 -multiple BRT: Rework structures and locks to be per-vdev
#16743a60ed3822 L2ARC: Move different stats updates earlier
#167588dc452d90 Fix some nits in zfs_getpages()
#16759534688948 Remove hash_elements_max accounting from DBUF and ARC
#167669a81484e3 ZAP: Reduce leaf array and free chunks fragmentation
#16773457f8b76e BRT: More optimizations after per-vdev splitting
#167820ca82c568 L2ARC: Stop rebuild before setting spa_final_txg
#16785d76d79fd2 zio: Avoid sleeping in the I/O path
#16791ae1d11882 BRT: Clear bv_entcount_dirty on destroy
#16796b3b0ce64d FreeBSD: Lock vnode in zfs_ioctl()
#16797d0a91b9f8 FreeBSD: Reduce copy_file_range() source lock to shared
Obtained from: OpenZFS
OpenZFS commit: d0a91b9f88
These tests try to verify that packet prioritisation works as expected. This is
inherently a statistical process, and is difficuly to measure automatically.
Run the tests more times and accept more failures.
Sponsored by: Rubicon Communications, LLC ("Netgate")