Right now pkill/pgrep cut off at _POSIX2_LINE_MAX (2048), but argument
strings can be much larger (ARG_MAX is 256K/512K). Stop arbitrarily
cutting the search off at 2K, rather than documenting the limit.
Reviewed by: allanjude (earlier version), des
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38663
The callers of dump_savectx() (i.e., doadump() and livedump_start())
subsequently call dumpsys()/minidumpsys(), which dump the calling
thread's stack when writing the dump. If dump_savectx() gets its own
stack frame, that frame might be clobbered when its caller later calls
dumpsys()/minidumpsys(), making it difficult for debuggers to unwind the
stack.
Fix this by making dump_savectx() a macro, so that savectx() is always
called directly by the function which subsequently calls
dumpsys()/minidumpsys().
This fixes stack unwinding for the panicking thread from arm64
minidumps. The same happened to work on amd64, but kgdb reports the
dump_savectx() calls as coming from dumpsys(), so in that case it
appears to work by accident.
Fixes: c9114f9f86 ("Add new vnode dumper to support live minidumps")
Reviewed by: mhorne, jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39151
We cannot just compare histsizeval() against 0, since that returns
a string pointer, which is always non-zero (non-null). The logic
in sethistsize() initializes the history size to 100 with values
that are non-number, and an empty string counts as that. Therefore,
the only time we want to not write into history with HISTSIZE val
set is when it's explicitly 0.
MFC after: 2 weeks
pfsync_undefer_state() takes the bucket lock, but could get called from
places (e.g. from pfsync_update_state() or pfsync_delete_state()) where
we already held the lock.
As it can also be called from places where we don't yet hold the lock
create new locked variant for use when the lock is already held. Keep
using pfsync_undefer_state() where the lock must still be taken.
PR: 268246
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC (Netgate)
The callout for pfsync_defer_tmo() is created with
CALLOUT_RETURNUNLOCKED, because while the callout framework takes care
of taking the lock we want to run a few operations outside of the lock,
so we unlock ourselves.
However, if `sc->sc_sync_if == NULL` we return without releasing the
lock, and leak the lock, causing later deadlocks.
Ensure we always release the bucket lock when we exit pfsync_defer_tmo()
PR: 268246
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC (Netgate)
Test the new unicast carp mode for IPv6.
There's a routing hop between the peers, to ensure that the TTL check is
correctly disabled for unicast carp.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D38942
Test the new unicast carp mode for IPv4.
There's a routing hop between the peers, to ensure that the TTL check is
correctly disabled for unicast carp.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D38941
Allow users to configure the address to send carp messages to. This
allows carp to be used in unicast mode, which is useful in certain
virtual configurations (e.g. AWS, VMWare ESXi, ...)
Reviewed by: melifaro
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D38940
Adding a missing include file, which provides the definition of
SYSCTL_INT.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39149
There's been at least one issue where we failed to correctly enter
NET_EPOCH that was triggered in this scenario.
Add a test case for it to make it easier to detect issues like this in
the future.
Reviewed by: zlei
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D39115
Allow carp configuration information to be supplied and retrieved via
netlink.
Reviewed by: melifaro
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D39048
The function pr_pack() prints out a packet, if the IP packet contains
options, these are printed as well.
Test the functionality fixed in
70960bb86a.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38470
Ping used to provide some sort of packet sniffing capabilities, this was
in an era where hubs were used and tcpdump wasn't invented.
pr_iph() is a function that prints the IP header of the packet.
pr_retip() is essentially a wrapper function to pr_iph(), that also
displays the source and destination ports of a TCP or UDP packet.
After ef9e6dc7ee some of this
functionality was almost removed, to only display packets sent by us
(26+ years ago).
At this point, reaching this code path was only possible by doctoring
the original packet.
After 46d7b45a26 this code path can never
be reached.
Remove the code.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38475
When an ICMP packet contains an IP packet in its payload, and that
original IP packet contains options, these options were not displayed
accordingly in pr_iph().
pr_iph() is a function that prints the original "quoted packet" IP
header, with only an IP struct as an argument. The IP struct does not
contain IP options, and it is not guaranteed that the options will be
contiguous in memory to the IP struct after
d9cacf605e.
Pass the raw ICMP data along with the IP struct, in order to print the
options, if any.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38469
Historically the system panic'ed when it encountered a corrupt
directory. This change recovers well enough to continue operations.
This change is made in response to a similar change made in the ext2
filesystem as described in the cited Differential Revision.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38503
Revision r333125 AKA 986c4ca387 forced clear cpu_stdext_feature3
on suspend, since at that time microcode update was not reloaded
early on resume. Then, revision 050f5a8405 started re-reading
cpu_stdext_feature3 again. Since modern CPUs do not require mitigations
from the Skylake era, this went unnoticed for some time.
Keep zeroing cpu_stdext_feature3 on suspend, but re-read it in more
controlled way on resume after microcode is reloaded, and recalculate
active workarounds based on actual microcode capabilities.
Reported and tested by: romain
Reviewed by: emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D39146
A number of improvements has commited to snl(3) recently.
A notable one is snl(3) build-in parsers for all of the objects
exported by the kernel.
This change updates netlink handling code to the latest available snl(3)
API.
Use .An -nosplit for the AUTHORS section, so that
it renders without an unnecessary newline.
No .Dd bump since it isn't a content change.
MFC after: 3 days
Azure setup does not like it when FreeBSD overrides the settings of the
UART device. When Hyper-V is detected, don't do this and also don't
throttle putc() output. This is a workaround for the early boot hang
of FreeBSD on Azure.
Tested on Azure, ESXi (VM with serial port), and SG-8200
PR: 264267
Reviewed by: kevans, whu
Tested by: whu
Obtained from: Rubicon Communications, LLC (Netgate)
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
UEFI provides ConIn/ConOut handles for consoles that it supports,
which include the text-video and serial ports. When the serial port
is available, use the UEFI driver instead of direct io-port accesses
to avoid conflicts between the firmware and direct hardware access, as
happens on Hyper-V (Azure) setups.
This change enables efiserialio to be built for efi-amd64 and has
higher order priority vs comconsole, and only uses efiserialio
if the hypervisor is Hyper-V. When efiserialio successfully
probes, it will set efi_comconsole_avail=true which will prevent
comconsole from probing in this setup.
Tested on Hyper-V, ESXi and Azure VMs.
PR: 264267
Reviewed by: kevans, whu
Tested by: whu
Obtained from: Rubicon Communications, LLC (Netgate)
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
The panic() will be called under ext2_dirbad()
function in case of rw mount. It cause user confusion,
like in BZ 265951.
PR: 265951
Reviewed by: pfg, mckusick
MFC after: 2 week
Differential revision: https://reviews.freebsd.org/D38503
Add check that directory entry with ino=EXT2_ROOTINO
have correct namelength and name. It is possible to
create malicious image which will cause panic if root
directory entry have incorrect name.
PR: 259068
Reported by: Robert Morris
Reviewed by: pfg
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D38502
Start breaking down big main()
Remove goto exit label and replace it with a function that does cleanup.
Comment re-worded by kevans@.
Pull Request: https://github.com/freebsd/freebsd-src/pull/694
And minor style fixes.
Reviewed by: hselasky
Tested by: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
Fixes: 0d7064d58f xhci(4): Add new USB IDs
Differential Revision: https://reviews.freebsd.org/D38921
