Some of the printf statements only use LF to get a newline. However, a CR character is also required for the serial console to print debug logs in a nice way.
Fix those code locations that only use LF, by adding a CR character.
Reviewed by: markj, aleksandr.fedorov@itglobal.com
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22552
When using sysrc to modify a file, the file should be created silently.
However, with the introduction of SVN r335280, an error of "No such file
or directory" would appear despite everything else working as-expected.
The nature of this spurious error is that SVN r335280 did not check if
the file exists first, before trying to fixup the line-endings in the
file just prior to modification.
PR: bin/240875
Reported by: Jose Luis Duran
MFC after: 3 days
foreground.
This allows a separate process to monitor when and how those programs exit.
That process can then restart them if needed.
Submitted by: Alex Burlyga
Reviewed by: bcr, imp
MFC after: 1 week
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D22474
This reapplies the RISC-V GNU ld workaround from r354896, r354899, and
354900, along with a fix for the build failure during cleandir.
LINKER_TYPE was not being set during cleandir, resulting in
Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
from Cirrus-CI.
PR: 242109
Sponsored by: The FreeBSD Foundation
Add code to decode the BootCurrent and BootXXXX variable it points at
to deduce the ESP used to boot the system. By default, it prints the
path to that device. With --unix-path (-p) it will instead print the
current mount point for the ESP, if any (or an error). With
--device-path (-d) it wil print the UEFI device path for the ESP.
Note: This is the best guess based on the UEFI variables. If the ESP
is part of a gmirror, etc, that won't be reported. If by some weird
chance there was a complicated series of chain boots, this may not be
what you want. For setups that don't add layers on top of the raw
devices, it is accurate.
Differential Revision: https://reviews.freebsd.org/D22432
This patch fixes a race condition where the receive callback is called
while the device is being reset. Since the rx_merge variable may change
during reset, the receive callback may operate inconsistently with what
the guest expects.
Also, get rid of the unused rx_vhdrlen variable.
PR: 242023
Reported by: aleksandr.fedorov@itglobal.com
Reviewed by: markj, jhb
MFC with: r354552
Differential Revision: https://reviews.freebsd.org/D22440
error: operator '?:' has lower precedence than '|'; '|' will be evaluated first
I discovered this in CheriBSD after updating our fork of clang to the latest
upstream master.
Reviewed By: ian
Differential Revision: https://reviews.freebsd.org/D22433
Since st_birthtime doesn't exists on Linux (unless you use statx(2)), we
instead populate it with the st_ctime value.
Reviewed By: emaste
Differential Revision: https://reviews.freebsd.org/D22386
Instead of providing ioctl cmd value, which has no meaning to user,
print MSR number. The later is what the user expects in this place
even.
Reported by: pstef
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Instead of calloc()ing (and forgetting to free) in a tight loop, just put
this small array on the stack.
Reported by: Coverity
Coverity CID: 1331665
MFC after: 2 weeks
Sponsored by: Axcient
sesutil would allow the user to toggle an LED that was one past the maximum
element. If he tried, ENCIOC_GETELMSTAT would return EINVAL.
Reported by: Coverity
Coverity CID: 1398940
MFC after: 2 weeks
Sponsored by: Axcient
At the end of both mevent_add() and mevent_update(), mevent_notify()
is called to wakeup the I/O thread, that will call kevent(changelist)
to update the kernel.
A race condition is possible where the client calls mevent_add() and
mevent_update(EV_ENABLE) before the I/O thread has the chance to wake
up and call mevent_build()+kevent(changelist) in response to mevent_add().
The mevent_add() is therefore ignored by the I/O thread, and
kevent(fd, EV_ENABLE) is called before kevent(fd, EV_ADD), resuliting
in a failure of the kevent(fd, EV_ENABLE) call.
PR: 241808
Reviewed by: jhb, markj
MFC with: r354288
Differential Revision: https://reviews.freebsd.org/D22286
via 'diskinfo -v'. This avoids the need to track it down via CAM,
and should also work for disks that don't use CAM. And since it's
inherited thru the GEOM hierarchy, in most cases one doesn't need
to walk the GEOM graph either, eg you can use it on a partition
instead of disk itself.
Reviewed by: allanjude, imp
Sponsored by: Klara Inc
Differential Revision: https://reviews.freebsd.org/D22249
Mergeable rx buffers is a virtio-net feature that allows the hypervisor
to use multiple RX descriptor chains to receive a single receive packet.
Without this feature, a TSO-enabled guest is compelled to publish only
64K (or 32K) long chains, and each of these large buffers is consumed
to receive a single packet, even a very short one. This is a waste of
memory, as a RX queue has room for 256 chains, which means up to 16MB
of buffer memory for each (single-queue) vtnet device.
With the feature on, the guest can publish 2K long chains, and the
hypervisor will merge them as needed.
This change also enables the feature in the netmap backend, which
supports virtio-net offloads. We plan to add support for the
tap backend too.
Note that differently from QEMU/KVM, here we implement one-copy receive,
while QEMU uses two copies.
Reviewed by: jhb
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D21007
If a VM is flooded with more ingress packets than the guest OS
can handle, the current virtio-net code will keep reading those
packets and drop most of them as no space is available in the
receive queue. This is an undesirable receive livelock, which
is a waste of CPU and memory resources and potentially opens to
DoS attacks.
With this change, virtio-net uses the new netbe_rx_disable()
function to disable ingress operation in the backend while the
guest is short on RX buffers. Once the guest makes more buffers
available to the RX virtqueue, ingress operation is enabled again
by calling netbe_rx_enable().
Reviewed by: bryanv, jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20987
The valectl(4) program is used to manage vale(4) switches.
Add it to the system commands so that it can be used right away.
This program was previously called vale-ctl, and stored in
tools/tools/netmap
Reviewed by: hrs, bcr, lwhsu, kevans
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22146
whitespace, and also reorder the fields so they are easier to read on
an 80 column display (the lines wrapped even before these changes).
Also fix non-standard nomenclature in the Caps code, and update the
man page.
Reported by: rpokala
standard nomenclature of "device" and "vendor" with the "sub" variants.
This changes the printed format, so anything that scrapes and parses
this will need to be adapted. No compatibility shims are provided,
but this will not be MFC'd.
Reviewed by: jhb, emaste, gtetlow
Approved by: jhb, emaste, gtetlow
Pass the list of user selected disks from zfsboot to bootconfig so that
the latter doesn't rely on ESP autodetection that apparently fails for
some cases, e.g. memstick installation with nvme (boot) and sata drives.
While here, fix printing of debug messages in bootconfig.
Reviewed by: bcran, imp, tsoome
Differential Revision: https://reviews.freebsd.org/D21930
This warning (comparing a pointer against a zero character literal
rather than NULL) has existed since GCC 7.1.0, and was recently added to
Clang trunk.
Almost all of these are harmless, except for fwcontrol's str2node, which
needs to both guard against dereferencing a NULL pointer (though in
practice it appears none of the callers will ever pass one in), as well
as ensure it doesn't parse the empty string as node 0 due to strtol's
awkward interface.
Submitted by: James Clarke <jtrc27@jrtc27.com>
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21914
'quarterly' package sets do not exist for head, so explicitly
install the 'latest' configuration file there. Otherwise,
fall back to the original conditional evaluation to determine
if the 'latest' or 'quarterly' configuration file should be
installed.
Reported by: manu
Reviewed by: manu
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
It seems reasonable to allow, for instance:
$ certctl list
# reviews output -- ah, yeah, I don't trust that one
$ certctl blacklist ce5e74ef.0
$ certctl rehash
We can unambiguously determine what cert "ce5e74ef.0" refers to, and we've
described it to them in `certctl list` output -- I see little sense in
forcing another level of filesystem inspection to determien what cert file
this physically corresponds to.
This change allows to specify a watchdog(9) timeout for a system
shutdown. The timeout is activated when the watchdogd daemon is
stopped. The idea is to a prevent any indefinite hang during late
stages of the shutdown. The feature is implemented in rc.d/watchdogd,
it builds upon watchdogd -x option.
Note that the shutdown timeout is not actiavted when the watchdogd
service is individually stopped by an operator. It is also not
activated for the 'shutdown' to the single-user mode. In those cases it
is assumed that the operator knows what they are doing and they have
means to recover the system should it hang.
Significant subchanges and implementation details:
- the argument to rc.shutdown, completely unused before, is assigned to
rc_shutdown variable that can be inspected by rc scripts
- init(8) passes "single" or "reboot" as the argument, this is not
changed
- the argument is not mandatory and if it is not set then rc_shutdown is
set to "unspecified"
- however, the default jail management scripts and jail configuration
examples have been updated to pass "jail" to rc.shutdown, just in case
- the new timeout can be set via watchdogd_shutdown_timeout rc option
- for consistency, the regular timeout can now be set via
watchdogd_timeout rc option
- watchdogd_shutdown_timeout and watchdogd_timeout override timeout
specifications in watchdogd_flags
- existing configurations, where the new rc options are not set, should
keep working as before
I am not particularly wed to any of the implementation specifics.
I am open to changing or removing any of them as long as the provided
functionality is the same (or very close) to the proposed one.
For example, I think it can be implemented without using watchdogd -x,
by means of watchdog(1) alone. In that case there would be a small
window between stopping watchdogd and running watchdog, but I think that
that is acceptable.
Reviewed by: bcr (man page changes)
MFC after: 5 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D21221
installer when installing the system on a ZFS root filesystem.
For arm64, zfs_load="YES" does not add opensolaris.ko as a kld
dependency, so add it explicitly to prevent boot-time failures
out-of-box.
PR: 240478
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
