loader.conf for uboot have this in the list, but the default one
didn't. Since there's no harm and it's a failsafe, add it to the list.
Sponsored by: Netflix
The PT_DETACH case above the sendsig: label already looped over all
threads clearing flags in td_dbgflags. Reuse this loop to clear
TDB_SUSPEND and move the logic out of the sendsig: block.
Most of the conditionals in the 'sendsig:' block are now only different
for PT_ATTACH vs other continue requests. Pull the PT_ATTACH-specific
logic up into the PT_ATTACH case and simplify the 'sendsig:' block. This
also permits moving the unlock of proctree_lock above the sendsig: label
since PT_KILL doesn't hold the lock and and the other cases all fall
through to the label.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D13073
loader.conf is also different between machines. On arm it's a minimal
one that's not quite compatible with the default one. On arm it's
minimal for speed, which is good, but there's also extra things in it
relative to the default on which break loading FDT which is bad. This
doesn't address that issue, but instead ensures the minimal one for
arm is used.
A similar issue for mips exists, but since we can have a beri variant
of /boot/loader and a uboot variant, I'm leaving that mess alone for
the moment.
Sponsored by: Netflix
This fixes a panic when attaching to an already-stopped process after
r325028. While here, clean up a few other things in the control flow
of the 'sendsig' section:
- Only check for P_STOPPED_TRACE rather than either of P_STOPPED_SIG
or P_STOPPED_TRACE for most ptrace requests. The signal handling
code in kern_sig.c never sets just P_STOPPED_SIG for a traced
process, so if P_STOPPED_SIG is stopped, P_STOPPED_TRACE should be
set anyway. Remove a related debug printf. Assuming P_STOPPED_TRACE
permits simplifications in the 'sendsig:' block.
- Move the block to clear the pending thread state up into a new
block conditional on P_STOPPED_TRACE and handle delivering pending
signals to the reporting thread and clearing the reporting thread's
state in this block.
- Consolidate case to send a signal to the process in a single case
for PT_ATTACH. The only case that could have been in the else before
was a PT_ATTACH where P_STOPPED_SIG was not set, so both instances
of kern_psignal() collapse down to just PT_ATTACH.
Reported by: pho, mmel
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D12837
Since r324184 the root node compatible for rpi2 is "brcm,bcm2836", add
it to the compatible list of bcm2835_cpufreq.
Tested On: RPI2 v1.1 RPI2 v1.2
Reported by: many on freebsd-arm@
in the LinuxKPI returns NULL. This happens when the VM area's private
data handle already exists and could cause a so-called NULL pointer
dereferencing issue prior to this fix.
Found by: greg@unrelenting.technology
MFC after: 1 week
Sponsored by: Mellanox Technologies
Note that PMCLOG_RESERVE_WITH_ERROR() macro contains goto error;
statement and executed after the flag is set.
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
only works because we have -Isys on the command line. We also have
-Isys/boot/userboot on the command line, so bring it in directly with
<userboot.h>. No functional change, but it removes one hard to see
dependency on the boot loader's location in sys/boot.
Sponsored by: Netflix
r325681 fixed a NULL pointer dereference on RPi3 caused by a lack of
functionality in uboot's EFI implementation. That rev checked the boot1
load path for NULL but not the load device. In practice if the former
works the latter will as well, but improve correctness by checking each
separately.
Submitted by: Keith White <kwhite@eecs.uottawa.ca>
Reported by: jhb
MFC after: 5 days
MFC with: r325681
Sponsored by: The FreeBSD Foundation
There were two things wrong. First, the wrong path was listed in .PATH
statement. Second, BOOTSRC wasn't yet defined for the .PATH, so it
didn't properly add it. Third, even if these were right, . was in the
path before, so it wouldn't have worked. Replace this with a simple
loop so the proper loader.rc gets selected.
Noticed by: dhw@ (menus stopped working on boot)
Sponsored by: Netflix
LinuxKPI task struct. Change type of "state" variable from "int" to
"atomic_t" to simplify code and avoid unneccessary casting.
MFC after: 1 week
Sponsored by: Mellanox Technologies
Also, move generation of loader.help into loader.mk. Set HELP_FILES=
to disable this (so we only install one help file, for now). At the
same time remove some duplicate -I lines. Fix several FILES= and
CLEANFILES= into the += form since we're touching both of those in the
.mk files. Make sure we only build one loader.help file per platform
in a unified way (we were building many on some, with the last to
install winning, though often they were the same text).
Also, we're now installing loader.rc and menu.rc everywhere. arm and
mips uboot installed these as menu.rc.sample, but there's no need
since the loader.rc for those platforms doesn't do menu.rc processing
by default. pcibios.4th is now installed everywhere, but will failsafe
on non x86 platforms (it isn't loaded by default anywhere).
These changes are too intertwined to do separately since aspects of
each are required to have a bug-free commit.
Sponsored by: Netflix
Transition to WITH/WITHOUT_LOADER_GELI to flag support or not of GELI
in the boot loaders. Add HAVE_GELI so components can flag they need
support (since it's too large to include everywhere). Add temporary
warnings for the old forms to ease transition.
Also, update test script to build without GELI on x86.
Sponsored by: Netflix
Rename LOADER_FIREWIRE_SUPPORT to MK_LOADER_FIREWIRE. Only build
libfirewire when this is "yes". Add note to updating. Fix build script
to build this for x86 so the option doesn't decay. sparc64 supports
ZFS, so also build it MK_ZFS=no.
Sponsored by: Netflix
LOADER_ZFS_SUPPORT is entirely used to select whether or not to
support ZFS in the loader. But it's not a user-servicable part (MK_ZFS
is what's used for that) Change it to the more conventional HAVE_ZFS
and move the ZFS support code into loader.mk. In addition, only build
ZFS libraries and boot loaders when ZFS is enabled.
Sponsored by: Netflix
LOADER_FDT_SUPPORT was used inconsistently in the tree. In some
places, it was used to control whether or not the user wanted FDT
included, and in other places it was a command to include
support. Remove it entirely. The former is now enabled -DWITH_FDT,
while the latter is controlled by Makefiles defining HAVE_FDT.
Supported by: Netflix
libfoo32 is only needed when compiling 32-bit libraries on native
64-bit architectures, and only when that 64-bit architecture needs
mixed 32-bit and 64-bit binaries.
Sponsored by: Netflix
Previously we passed tx packets to hardware via nicvf_tx_mbuf_locked
and then to the BPF tap, with a possibly invalid mbuf which would result
in a panic.
PR: 223600
Discussed with: bz
MFC after: 1 week
Sponsored by: The FreeBSD Foundation, Packet.net (hardware)
As of r323063 boot1 printed out the path & device from which it was
loaded, but uboot's EFI implementation lacked some support, resulting in
a NULL pointer and a crash. Check for a NULL pointer and avoid
reporting (and storing in the environment) the device and path in this
case.
Submitted by: Zakary Nafziger <worldofzak@gmail.com>
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13038
instead of asserting the condition.
The row index is directly supplied by userspace, the kernel must
handle invalid values.
Submitted by: pho
MFC after: 3 days
would attempt to re-allocate interrupts during a chip reset without
first de-allocating them. Doing that right is going to be tricky, so
just band-aid it for now so that a re-init doesn't guarantee a failure
due to resource re-use.
Reported by: gallatin
Sponsored by: Netflix
