supported on newer POWER hardware and in graphical VMs run on the same,
which are typically XHCI-only. The 32-bit GENERIC kernel, which
does not run on hardware made in the last decade and is unlikely to
encounter XHCI devices, is left unchanged.
PR: kern/224940
Submitted by: Gustavo Romero
MFC after: 1 week
inline ccbque.h into scsi_low.h. The file isn't MD, so shouldn't live
in i386/isa. It's only used by scsi_low, so move it there so no new
clients accidentally grow. scsi_low may not even still work, and the
locking here is still SPL based. CAM should do the right thing, but
I've received no reports of these cards still working. At least it
compiles still and there's one fewer files in sys/i386/isa. While I'm
here, ansify and de-splize. CCB_MWANTED appears to be a clear-only
flag, but I've not changed that.
Differential Review: https://reviews.freebsd.org/D13672
a mask and value to compare with the Main ID Register. If these match then a
function is called to handle the installation of the erratum workaround.
No errata are currently handled, however this will change soon in a future
commit.
MFC after: 1 week
Sponsored by: DARPA, AFRL
This is a followup to r307903.
struct svm_softc takes more than 200 kilobytes while what we really need
is 3 contiguous pages for I/O permission map and 2 contiguous pages for
MSR permission map. Other physically mapped structures have a size of
a single page, so a proper alignment is sufficient for their correct
mapping.
Thus, only the permission maps are allocated with contigmalloc now,
the softc is allocated with a regular malloc.
Additionally, this commit adds a check that malloc returns memory with the
expected page alignment and that contigmalloc does not fail.
Unfortunately, at present svm_vminit() is expected to always succeed and
there is no way to report an error.
So, a contigmalloc failure leads to a panic.
We should probably fix this.
MFC after: 2 weeks
The code accesses bp->b_dep without owning the ufs mount softdep lock,
which makes it possible for the derefenced workitem to be freed in
parallel. In particular, the deallocate_dependencies(),
softdep_disk_io_initiation() and softdep_disk_write_complete() are
affected.
Move the code to safely calculate ump from the buffer with
dependencies into the helper softdep_bp_to_mp() and use it for all
found cases.
Tested by: pho (as part of the bigger patch)
Reviewed by: mckusick (as part of the bigger patch)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
handle_written_XXX() in case of processing the buffer with an error.
Tested by: pho (as part of the bigger patch)
Reviewed by: mckusick (as part of the bigger patch)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
so that buf_complete() sees fully constructed buffer.
This is a NOP right now, but will be needed by the forthcoming SU change.
Reported and tested by: pho
Reviewed by: mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
that was not allocated will be accessed.
This necessitated refactoring state seed allocation from
ipf_state_soft_init() into a new common ipf_state_seed_alloc() function
as it is now also used by ipf_state_rehash() when changing the size of
the state hash table in addition to by ipf_state_soft_init() during
initialization.
According to Christos Zoulas <christos@NetBSD.org>:
The bug was encountered by a NetBSD vendor who's customer machines had
large ipfilter states. The bug was reliably triggered by resizing the
state variables using "ipf -T".
Submitted by: Christos Zoulas <christos@NetBSD.org>
Reviewed by: delphij, rgrimes
Obtained from: NetBSD ip_state.c CVS revs r1.9 and r1.10
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13755
By disabling the -Winline warning. Fixes the powerpc and sparc64 build
after r327706.
Note: MIPS and RISCV builds still broken due to absense of __ctzdi2 (aka
__builtin_ctzll) in their libgcc or libcompiler-rt libraries.
Reported by: markj
Sponsored by: Dell EMC Isilon
from the ada and da dump routines. This avoids difficult locking
problems from needing to be handled. While it might seem like this
would leave the periphs unprotected during dump, they were aleady
at risk of unexpected removal due to the dump functions not
keeping refcount state across the many calls that come in during
a dump. This is an exercise for future work.
Obtained from: Netflix
We currently use a set of subroutines in kern_gzio.c to perform
compression of user and kernel core dumps. In the interest of adding
support for other compression algorithms (zstd) in this role without
complicating the API consumers, add a simple compressor API which can be
used to select an algorithm.
Also change the (non-default) GZIO kernel option to not enable
compressed user cores by default. It's not clear that such a default
would be desirable with support for multiple algorithms implemented,
and it's inconsistent in that it isn't applied to kernel dumps.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D13632
Mock userspace headers and include mocked headers first in compilation
command to inject kernel headers and override e.g., malloc(3) with
malloc(9).
Submitted by: allanjude
Reviewed by: imp (earlier version), bapt (earlier version)
Differential Revision: https://reviews.freebsd.org/D10407
malloc(9): drop the __result_use_check attribute for the kernel allocator.
My bad: __result_use_check just checks the for the general and we always
want to make sure allocated memory is used, not only checked for nullness.
Add it to reallocf since that was missing.
The __result_use_check attribute was brought to the kernel malloc in
r281203 for consistency with the userland malloc.
For the case of the M_WAITOK flag, the kernel malloc(), realloc(), and
reallocf() cannot return NULL so in that case the __result_use_check
attribute makes no sense.
We don't have any way of conditionalizing such attributes so just drop it.
MFC after: 3 days
pfioctl() handles several ioctl that takes variable length input, these
include:
- DIOCRADDTABLES
- DIOCRDELTABLES
- DIOCRGETTABLES
- DIOCRGETTSTATS
- DIOCRCLRTSTATS
- DIOCRSETTFLAGS
All of them take a pfioc_table struct as input from userland. One of
its elements (pfrio_size) is used in a buffer length calculation.
The calculation contains an integer overflow which if triggered can lead
to out of bound reads and writes later on.
Reported by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Similar to calloc() the mallocarray() function checks for integer
overflows before allocating memory.
It does not zero memory, unless the M_ZERO flag is set.
Reviewed by: pfg, vangyzen (previous version), imp (previous version)
Obtained from: OpenBSD
Differential Revision: https://reviews.freebsd.org/D13766
The sid controller on the H3 is generally identical in location, size, and
efuse offset to the a64 and the a83t. The main difference is that the H3 has
a silicon bug that sometimes causes the rootkey (at least) to be garbled
unless first read by the prctl registers.
This device is currently not in our DTS and, as of now, is not yet present
in mainline Linux DTS.
Tested on: OrangePi One
Technically supported on the later SoCs, this will only really be used to
add support for the H3 sid. The H3 has a silicon bug that manifests itself
by returning garbled rootkeys unless first read via the prctl registers.
ian@ pointed out that BUS_PASS_DEFAULT + $anything is bogus, given that
BUS_PASS_DEFAULT is defined as __INT_MAX. Instead, we take a page out of
imx6_usbphy's book and use BUS_PASS_DEFAULT - 1000 to achieve the desired
effect of syscon_generic attaching before if_awg and other potential
consumers, but late enough that more specialized implementations should have
no problem attaching instead.
Reported by: ian
It still needs to be before if_awg at least in order to be available for
other operations, but it should not be attaching before interrupt
controllers at the very least.
This should make errors involving syscon register space colliding with other
devices a little more innocent, but these conflicts should really be tracked
down and resolved. One such conflict is with the Raspberry Pi 3 local
interrupt controller, noticed by tuexen@
Reported by: tuexen
After recent changes to change filesystems to use filesystem-specific
limits, LINK_MAX is no longer used in the base system. Applications
should in theory be able to cope with a lack of LINK_MAX by using
pathconf().
PR: 224628 (exp-run)
Approved by: imp, kib
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D13658
Add cpuctl(4) ioctl CPUCTL_EVAL_CPU_FEATURES which forces re-read of
cpu_features, cpu_features2, cpu_stdext_features, and
std_stdext_features2.
The intent is to allow the kernel to see the changes in the CPU
features after micocode update. Of course, the update is not atomic
across variables and not synchronized with readers. See the man page
warning as well.
Reviewed by: imp (previous version), jilles
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D13770
The emac bindings that are landing in Linux 4.15 specify a syscon property
on the emac node that point to /soc/syscon. Use this property if it's
specified, but maintain backwards compatibility with the old method.
The older method is still used for boards that we get .dtb from u-boot, such
as pine64, that did not yet have stable emac bindings.
Tested on: Banana Pi-M3 (a83t)
Tested on: Pine64 (a64)
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D13296
This avoids re-reading a variable after it has been updated via an
atomic op. It is just a cosmetic cleanup as the read value was only
used to control a diagnostic printf that should rarely occur (if ever).
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D13768
