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
(cherry picked from commit 5317480967bfc8bf678e4da3fce81bcb3f5b7836)
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
(cherry picked from commit 6d4c59e26189a8c19fd0832e89f9b089330cbfcb)
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
(cherry picked from commit 2839ad58dd8a4cf5294180fc599800c437a8d4d8)
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
(cherry picked from commit 5ac39263d825d7b2f8a89614a63fee90ffc77c07)
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
(cherry picked from commit 5bd08172b4150503c9cf60ffe3c97716c5bf6fa1)
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/1505
(cherry picked from commit 1f78bbb5c415efefa782c1be7f9a2e4a5008903b)
newsyslog.conf(5): Remove duplicate word
Reported by: jlduran
Fixes: 1f78bbb5c415 newsyslog.conf(5): Accept human unit suffix in the size filed
(cherry picked from commit af2015b01f7e741125aeb4a04109cc42f988cf0f)
This function is registered as a ifnet_link_event and so should have the
corresponding argument list.
PR: 282870
Reported by: nakayamakenjiro@gmail.com
MFC after: 1 week
(cherry picked from commit 0289db3259532d51ebe58bc0b2647a0d9e6cae66)
These tests assume exclusive use of one or more FIBs and so can't be run
in parallel. Running them in a VNET jail sidesteps this problem.
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
(cherry picked from commit a079f2b52aae74b5469f18dcbef1aff680b80282)
- Use the local var "laddr" instead of sin->sin_addr in one block.
- Use in_nullhost() instead of explicit comparisons with INADDR_ANY.
- Combine multiple socket options checks into one.
- Fix indentation.
- Remove some unhelpful comments.
This is in preparation for some simplification and bug-fixing.
No functional change intended.
Reviewed by: glebius
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D47451
(cherry picked from commit 45a77bf23fa2f36bf2169f7ba2a33b31f4c35adb)
Readahead/behind pages are handled by the swap pager, but the get_pages
caller is responsible for putting fetched pages into queues (or wiring
them beforehand).
Note that the VM object lock prevents the newly queued page from being
immediately reclaimed in the window before it is marked dirty by
swap_pager_swapoff_object().
Reported by: pho
Tested by: pho
Reviewed by: dougm, alc, kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47526
(cherry picked from commit d11d407aee4835fd50811a5980125bb46748fa0b)
atomic(9) primitives are documented as operating on unsigned types.
Here, we need a cast to avoid a tautological comparison.
Add a regression test for access(2), which was affected by the bug.
Reported by: NetApp
Reviewed by: kib
Fixes: e511bd1406 ("vfs: fully lockless v_writecount adjustment")
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D47672
(cherry picked from commit 4ff291ebe80a226295351936d99fc6e3e7fce48a)
Other atf components are guarded by WITH_TESTS_SUPPORT already.
WITH_TESTS is for actual tests.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47660
(cherry picked from commit 43e045c1733d50fad79f3a53e05140b8dc0d7fa6)
If we fail to attach the new state keys in pf_state_key_attach() we are
expected to free both keys. Do so.
Note that in some scenarios both key are the same, so check for that
before freeing.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47495
(cherry picked from commit 371bd29d4b22257a7e92e1e711cca3d94cfbd00d)
This is a retread of https://reviews.freebsd.org/D34449 which I think
will fix the issue for the remote side not supporting autoneg. We now
attempt an autoneg, and if that fails fall back to the current code
that forces the link speed/duplex.
The original intent of this patch is to inform the remote switch of
duplex settings when we (the client) are specifying a fixed 10 or 100
speed. Otherwise it may get the duplex setting wrong.
The tricky case is when the remote (switch) side is fixing its
speed AND duplex while disabling autoneg and we (client) need to do
the same, which still seems to be common enough at some ISPs.
Original commit message follows:
Currently if an e1000 interface is set to a fixed media configuration,
for gigabit, it will participate in auto-negotiation as required by
IEEE 802.3-2018 Clause 37. However, if set to fixed media configuration
for 100 or 10, it does NOT participate in auto-negotiation.
By my reading of Clauses 28 and 37, while auto-negotiation is optional
for 100 and 10, it is not prohibited and is, in fact, "highly
recommended".
This patch enables auto-negotiation for fixed 100 and 10 media
configuration, in a similar manner to that already performed for 1000.
I.e., the patch enables advertising of just the manually configured
settings with the goal of allowing the remote end to match the manually
configured settings if it has them available.
To be clear, this patch does NOT allow an em(4) interface that has been
manually configured with specific media settings to respond to
auto-negotiation by then configuring different parameters to those that
were manually configured. The intent of this patch is to fully comply
with the requirements of Clause 37, but for 100 and 10.
The need for this has arisen on an em(4) link where the other end is
under a different administrative control and is set to full
auto-negotiation. Due to the cable length GigE is not working well. It
is desired to set the em(4) end to "media 100baseTX mediatype
full-duplex" which does work when both ends are configured that way.
Currently, because em(4) does not participate in autoneg for this
setting, the remote defaults to half-duplex - i.e., there's a duplex
mismatch and things don't work. With this patch, em(4) would inform the
remote that it has only 100baseTX full, the remote would match that and
it will work.
Tested by: Natalino Picone <natalino.picone@nozominetworks.com>
Tested by: Franco Fichtner <franco@opnsense.org>
Tested by: J.R. Oldroyd <fbsd@opal.com> (previous version)
Sponsored by: Nozomi Networks
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D47336
(cherry picked from commit bceec3d80a3caf9249e24247fb937674bf5b46b5)
Add prototype. Export from libdl.
Fixes: 1426fd6cff0603f0ee275b99f2ba35dc36f3d0c2
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 209fd89a2810419309944f10d11834321f0ebb25)
Some sanitizers need to be able to use dl_iterate_phdr() after stopping
the rest of the process, but it's very hard to do so reliably as a
non-participant in the main logic of the program.
Introduce _dl_iterate_phdr_locked to bypass the locking that's normally
required for dl_iterate_phdr() and slap some scary warning on it. It
will remain undocumented and probably shouldn't be used for anything
else.
Reviewed by: kib
(cherry picked from commit 1426fd6cff0603f0ee275b99f2ba35dc36f3d0c2)
With some copy-editing to account for the man page being in
section 7 on stable/14.
PR: 282867
MFC: stable/14
Approved by: mhorne (via IRC)
(cherry picked from commit 3a212cc66ad1b5d6c1dc97eb07143e919a123491)
Follow the existing pattern of fflush() in verbose mode.
PR: 71665
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 75d11bfbc6d4289e4b3d91414e46a3af51f4402a)
Our implementation currently diverges from POSIX 2024 in a couple of
ways, as now noted in the BUGS section.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47589
(cherry picked from commit 95b71a659a9bdc6e9071d80c7369a935c2bc16f4)
sysctl(8) prints a newline after the description; the description should
not end with one itself.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 6b62e00da4ad0624fce5e6f0b5b39a6f44c8ba60)
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to change the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Sponsored by: Netflix
(cherry picked from commit ab540d44ba3201ff8313b90ba0096004603b2e34)
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to change the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Reviewed by: rrs
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44259
(cherry picked from commit 90853dfac851afa9e8840f5a38383256d75458b6)
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to fix the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Michael notes emperically 82599 has an unexpected middle mask:
Chip First Middle Last
82599 0xFF6 0xFF6 0xF7F
which should be fixed up to 0xF76 (RFC 3168) in a future commit.
Reviewed by: rrs, rscheff
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44258
(cherry picked from commit eea2e089f8dadf850a30ed837edd7a386427a9ed)
These were removed in a40ecb6f7405 because they do not apply to igc
hardware which uses EITR for interval timing.
Sponsored by: BBOX.io
(cherry picked from commit 8de007ad19dcda5bea9bac9fb2c140e4ed62ba78)
It was pointed out that the current approach of exhaustively searching
for a free source port might be very time consuming. Limit the amount
of work that we might do before giving up.
Reviewed by: kp
Reported by: Eirik Øverby <ltning-freebsd@anduin.net>
MFC after: 3 months
Sponsored by: Klara, Inc.
Sponsored by: Modirum
Differential Revision: https://reviews.freebsd.org/D46495
(cherry picked from commit 339a1977c32414f3d23733504955245ca6f3802d)
This should have been done with commit d9fe71828797 but was missed.
Fixes: d9fe71828797 ("makefs: Remove the warning printed when makefs -t zfs is used")
MFC after: 3 days
(cherry picked from commit e19c607ff9b2b5d55664fd13e5fd9814e3279ffd)
Key code swapping between [<>] and [^°] key is enabled for all Apple ISO
type keyboards. Before, swapping was enabled when the Eject key was
detected in HID usage. This did not correlate well with the swapped
keys presence.
usbdevs file is extended by several Apple keyboard models to support ISO
model identification.
Reviewed by: markj
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/1506
(cherry picked from commit 541e7a98b762916cd951a64dd7e77efd51dfa8dc)
As suggested by jrtc27@ in https://reviews.freebsd.org/D42415, this
patch enables IE as default thread-local storage model in libc on arm.
Reviewed by: kib
Approved by: kp (mentor)
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D42445
(cherry picked from commit 6e5b1ff71e01bd48172483cb6df921f84300ea3a)
net/frr[89] revealed an interesting edge-case on arm when dynamically
linking a shared library that declares more than one static TLS variable
with at least one using the "initial-exec" TLS model. In the case
of frr[89], this library was libfrr.so which essentially does the
following:
#include <stdio.h>
#include "lib.h"
static __thread int *a
__attribute__((tls_model("initial-exec")));
void lib_test()
{
static __thread int b = -1;
printf("&a = %p\n", &a);
printf(" a = %p\n", a);
printf("\n");
printf("&b = %p\n", &b);
printf(" b = %d\n", b);
}
Allocates a file scoped `static __thread` pointer with
tls_model("initial-exec") and later a block scoped TLS int. Notice in
the above minimal reproducer, `b == -1`. The relocation process does
the wrong thing and ends up pointing both `a` and `b` at the same place
in memory.
The output of the above in the broken state is:
&a = 0x4009c018
a = 0xffffffff
&b = 0x4009c018
b = -1
With the patch applied, the output becomes:
&a = 0x4009c01c
a = 0x0
&b = 0x4009c018
b = -1
Reviewed by: kib
Approved by: kp (mentor)
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D42415/
(cherry picked from commit 98fd69f0090da73d9d0451bd769d7752468284c6)
LSan wants to be able to register atfork handlers at __lsan_init time,
which can happen either at the first intercepted function call or in a
.preinit_array function. Both of these end up being very early in rtld
and executed with the bind lock held, which ends up causing problems
when we go to _libpthread_init().
Instead of requiring libpthread to be initialized, just insert the new
atfork handler straight into the list if it's not ready yet. The
critical section and locking should not be necessary if we're really
executing this early, as there won't be any threads to contend with.
Reviewed by: kib (earlier version), markj
(cherry picked from commit 4b202f4faf40fd7af8b84491360186aed8ce5733)
Test that it generally functions, and also that registering multiple
times calls each handler in the order that it's documented to call them
in.
Reviewed by: kib, markj
(cherry picked from commit 7e6ac503ffeb81733272d54af367db58e45e57ca)
