usr.bin/tftp: remove tests when MK_TFTP=no
These tests require the tftp client, which is not installed when
`MK_TFTP=no`. Remove them when that's not true.
MFC after: 1 week
usr.bin/factor: remove tests when MK_GAMES=no
factor(1) is only installed when MK_GAMES != no. Ergo, remove the tests
when that's not true.
MFC after: 1 week
tpm: crb: add support for the Pluton startmethod
The Pluton startmethod uses a simple doorbell mechanism to wakeup the
TPM unit after we've issued various forms of state change, with the
registers to use specified in the startmethod-specific segment of the
TPM2 table (up to 12 bytes after the StartMethod).
At the very least, this is the kind of TPM in use by my AMD Zen 4-based
Minisforum machine.
Differential Revision: https://reviews.freebsd.org/D53683
powerpc/pmap/oea64: Make PV_LOCK superpage sized
HPT superpages are 16MB, not 2MB. Taking 8 locks to lock a super page
almost defeats the purpose of using the super page. Expanding the
PV_LOCK scope to cover 16MB (24 bit shift) reduces this to a single
lock.
MFC after: 3 weeks
powerpc/pmap: Mark more CPUs as lockless TLBIE
Add POWER10 and POWER11 to the list of lockless TLBIE capable CPUs.
According to Linux, anything POWER5 and later should be able to do this,
but that hasn't been tested with FreeBSD. POWER10 and POWER11, being
derived after the POWER9, implicitly have this capability per the ISA
spec.
MFC after: 1 week
uart: fix sleeping while holding mutex in uart_tty_detach()
Move swi_remove() call before acquiring the tty lock. swi_remove() calls
intr_event_remove_handler() which may sleep via msleep(), causing a lock
order violation when called with the tty mutex held.
The software interrupt handler removal operates on the interrupt event
structure independently and does not require the tty lock. This matches
the pattern used in other drivers such as tcp_hpts.c where swi_remove()
is called without holding other locks.
Reviewed by: imp, kevans
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54953
rc: run the zfs rc script before tmp
The tmp rc script has much the same problem that the var does: it wants
to test if /tmp is writable, and mount a tmpfs if it's not. This means
that we actually want our zfs datasets mounted first, because we might
have a /tmp dataset that changes the story.
The ordering problem is particularly noticable with a r/o zfs root,
since the write test will fail and we'll mount a tmpfs that later gets
covered by our /tmp dataset. If that /tmp dataset inherited readonly,
then we're still in trouble.
This also fixes `tmpmfs=yes`, which would again get covered by a zfs
dataset with the existing ordering.
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D54995
Re-introduce kern.sched.topology_spec
Move it back from kern.sched.ule.topology_spec.
Make it scheduler-agnostic.
Provide trivial report for UP kernels.
Apparently the MIB is used by some third-party software. Obviously it
did not worked on UP or 4BSD configs.
PR: 292574
Reviewed by: olce
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D55062
pflog: tests: Fix rdr_action_head()
Fix a typo in the rdr_action_head() test.
Fixes: 685fb4253819 ("pf: Log the intended action when a NAT rule matches a packet")
MFC after: 1 week
(cherry picked from commit 964d91ee1d7a1405383aeb4fce72c4e3bc80af35)
acpi: add Darwin OSI quirk for Apple Mac hardware
Mac firmware hides the Intel integrated GPU (iGPU) on dual GPU x86
systems, i.e., with AMD/NVIDIA dGPUs, when the Darwin OSI is not
installed via ACPI.
Prior to this change, FreeBSD always used the dGPU. This is fine in
practice, but consumed more power than when the iGPU is used,
resulting in reduced battery life.
Linux handles this in `drivers/acpi/osi.c` by detecting Apple
hardware via DMI, disabling all Windows OSI strings, and
by explicitly installing the Darwin OSI ACPI handler. This change
applies equivalent logic to the acpi(4) driver on FreeBSD.
This feature can be enabled/disabled using the
`hw.acpi.apple_darwin_osi` tunable. Setting this tunable to `0`
restores the previous behavior by explicitly disabling the added
support.
[3 lines not shown]
acpi: Post/pre device suspend/resume eventhandlers
These eventhandlers are called after suspending the device tree and
before resuming it. This is useful for PMC (power management controller)
drivers.
Reviewed by: olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48735
acpi_spmc: Register SPMC suspend/resume routines
SPMC suspend runs after the device tree is suspended using the
acpi_post_dev_suspend eventhandler, and SPMC resume runs before the
device tree is resumed using the acpi_pre_dev_suspend eventhandler.
Reviewed by: olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48735
heimdal: Pass the correct pointer to realloc when growing a string buffer
The realloc in my_fgetln was trying to grow the pointer to the string
buffer, not the string buffer itself.
In function 'my_fgetln',
inlined from 'mit_prop_dump' at crypto/heimdal/kdc/mit_dump.c:156:19:
crypto/heimdal/kdc/mit_dump.c:119:13: error: 'realloc' called on unallocated object 'line' [-Werror=free-nonheap-object]
119 | n = realloc(buf, *sz + (*sz >> 1));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
crypto/heimdal/kdc/mit_dump.c: In function 'mit_prop_dump':
crypto/heimdal/kdc/mit_dump.c:139:11: note: declared here
139 | char *line = NULL;
| ^~~~
Reviewed by: rmacklem, cy
Fixes: a93e1b731ae4 ("heimdal-kadmin: Add support for the -f dump option")
Differential Revision: https://reviews.freebsd.org/D54933
(cherry picked from commit 03d8ac948b1ad9c419b294c3129b7da58d818363)
iicbb: Fix gcc12 complaint
So gcc12 doesn't understand that t->udelay is >= 1, so thinks that noack
might be unset sometimes. While we specifically constrain this on direct
assignment, there's a sysctl that might not. This is likely also a bug.
Instead of uglifying everything by using MAX(1, sc->udelay), I rewrote
the for loop as a do-while loop (which arguably dictates intent better
because this code clearly assumes it will be executed once).
Sponsored by: Netflix
(cherry picked from commit 4b301f7e7ab43bb61561786c2ab33f3a3c4a725d)
runat: Add -h to manipulate a symlink's named attribute dir
Lionel Cons <lionelcons1972 at gmail.com> requested
that a new option be added to runat(1) so that it could
be used to manipulate named attributes associated with
a symbolic link and not the file the symbolic link refers to).
This patch adds the option -h/--nofollow to do this.
Requested by: Lionel Cons <lionelcons1972 at gmail.com>
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D55023
sym(4): Map HCB memory as uncacheable also on x86
As part of making the chip-specific mix and match of different accesses
(DMA/bus space) work as desired, the intent is to map the HCB memory as
uncacheable. Prior to VM_MEMATTR_*, the !x86 way of indicating this to
bus_dmamem_alloc(9) was BUS_DMA_COHERENT. Then later on in 2db99100a4,
BUS_DMA_NOCACHE was hooked up to VM_MEMATTR_UNCACHEABLE for x86. As it
turns out, still as of today bus_dmamem_alloc(9) differs in this regard
across architectures. On arm, it still supports BUS_DMA_COHERENT only
for requesting uncacheable DMA and x86 still uses BUS_DMA_NOCACHE only.
On arm64 and riscv, BUS_DMA_COHERENT seems to effectively be an alias
for BUS_DMA_NOCACHE.
Thus, allocate the HCB memory with BUS_DMA_COHERENT | BUS_DMA_NOCACHE,
so we get uncacheable memory on all architectures including x86 and so
loads and stores from/to HCB won't get reordered. However, even on x86
we still need to use at least compiler barriers to achieve the desired
program order.
[10 lines not shown]
Revert "sym(4): Employ memory barriers also on x86"
The problem will be avoided in a different way.
This reverts commit e769bc77184312b6137a9b180c97b87c0760b849.
rpc: correct resultproc_t's type
It takes exactly three arguments of known type.
Tweak the types of various resultproc_t functions to match the type (mostly
added const to struct pointers) allowing us to drop casts.
Effort: CHERI upstreaming
Reviewed by: vangyzen, glebius
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54941
clnt_broadcast(3): fix eachresult argument type
The `eachresult` argument is documented to take a function pointer of
type:
bool_t (*)(caddr_t, struct sockaddr_in *)
It was declared to take a resultproc_t which has historically been
declared to be:
bool_t (*resultproc_t)(caddr_t, ...);
This overlapped well enough for currently supported ABIs where variadic
arguments are passed in registers, but this declaration is misaligned
with the documentation (resultproc_t takes three arguments) and will be
fixed in a followup commit.
Fix the type to be non-variadic, matching callbacks, and define a
convenience type of as most callbacks take something other than a char *
[6 lines not shown]
clnt_broadcast(3): don't free function pointers
Replace use of thr_getspecific/thr_setspecific to stash the function
pointer we're smuggling between clnt_broadcast and rpc_wrap_bcast with a
simple thread local variable. Clear it after use so the reference
doesn't linger.
In the relatively unlikely event clnt_broadcast was called from threads
that exited prior to program termination, the previous code called free
on a function pointer, which is undefined and might corrupted allocator
state.
Effort: CHERI upstreaming
Reviewed by: glebius, jhb
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54939
