devstat: Provide 32-bit compatibility
If a 32-bit process running on a 64-bit kernel requests kern.devstat.all,
translate each struct devstat to its 32-bit equivalent before copying it
out.
Also fix a bug where an early error would be ignored if there were no
devices to report.
MFC after: 1 week
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D54591
(cherry picked from commit a11d132f6c62f32abe44b19f7527d97ddc239058)
freebsd32: Fix includes
The previous commit added <sys/cdefs.h>, which isn't actually needed.
Conversely, <sys/event.h> is needed (and has been for a long time) but
[7 lines not shown]
ixgbe: Fix MRQC register value.
Focus on the MRQE field of the MRQC register, which is 4 bits wide,
and we use these 3 types of values.
- IXGBE_MRQC_RSSEN 0x1 (non VF mode)
- IXGBE_MRQC_VMDQRSS32EN 0xA (less than 33 VFs)
- IXGBE_MRQC_VMDQRSS64EN 0xB (less than 65 VFs)
If we always take a bitwise OR with IXGBE_MRQC_RSSEN,
IXGBE_MRQC_VMDQRSS32EN will never be chosen.
Select these 3 types of values for the proper case.
Signed-off-by: Yuichiro NAITO <naito.yuichiro at gmail.com>
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2132
kern/amd64/machdep: Replace memset in wrmsr_early_safe_end
GENERIC-KASAN kernel failed to boot on a Dell PowerEdge C6615 with
an AMD EPYC 8224P CPU; UEFI BIOS caught a #GP exception with %RIP
in kasan_memset where %GS relative pointer (curthread->td_pflags2)
was dereferenced. Investigation led to wrmsr_early_safe_end which
calls memset to clear early #GP IDT entry. Replacing memset with
__builtin_memset_inline still resulted in the compiler emitting a
call to the memset resolver in GENERIC-KASAN build and the kernel
stil faulted during boot. This version which has been successfully
tested with both GENERIC and GENERIC-KASAN kernels uses memset_early.
Signed-off-by: Kristofer Peterson <kris at tranception.com>
Reviewed-by: kib
(cherry picked from commit 615f1b9eb17c921bbcb0cce2b9ad61910361325b)
ls: check fts_children() for errors that may not surface otherwise
In particular, if one simply does a non-recursive `ls` on a directory
that is not accessible, there are some classes of errors that may cause
it to fail that wouldn't be surfaced unless we do an fts_read() that
will recurse into the inaccessible directory. Catch those kinds of
errors here since we cannot expect to an FTS_ERR/FTS_DNR entry to follow
up on them.
PR: 287451
Reviewed by: kib
Discusssed with: des
(cherry picked from commit 7bf81e39d83087dc7f984077b5eed5a48df794d4)
