Andriy Gapon [Wed, 15 Dec 2021 11:37:59 +0000 (13:37 +0200)]
mmc_sim: fix setting of the mutex name
To quote the manual:
The pointer passed in as name and type is saved rather than the data
it points to. The data pointed to must remain stable until the mutex
is destroyed.
It seems that the type is actually copied, but the name is stored as
a pointer indeed.
mmc_cam_sim_alloc used a name stored on stack.
So, a corrupt mutex name would be reported.
For example:
lock order reversal: (sleepable after non-sleepable)
1st 0xd7285b20 <8A><C0><C0>P@<C1><D0>P@<C1>^D^A (aw_mmc_sim, sleep mutex) @ sys/cam/cam_xpt.c:2804
This change moves the name to struct mmc_sim.
Also, that name is used as the sim name as well.
Unused mtx_name variable is removed too.
The name buffer is reduced to 16 characters.
Rick Macklem [Sat, 11 Dec 2021 23:00:30 +0000 (15:00 -0800)]
nfscl: Fix must_commit/writeverf handling for Direct I/O
Without this patch, the KASSERT(must_commit == 0,..) can be
triggered by the writeverf in the Direct I/O write reply changing.
This is not a situation that should cause a panic(). Correct
handling is to ignore the change in "writeverf" for Direct
I/O, since it is done with NFSWRITE_FILESYNC.
This patch modifies the semantics of the "must_commit"
argument slightly, allowing an initial value of 2 to indicate
that a change in "writeverf" should be ignored.
It also fixes the KASSERT()s.
This bug would affect few, since Direct I/O is not enabled
by default and "writeverf" rarely changes. Normally "writeverf"
only changes when a NFS server reboots, however I found the
bug when testing against a Linux 5.15.1 kernel nfsd, which
replied to a NFSWRITE_FILESYNC write with a "writeverf" of all
0x0 bytes.
Alexander Motin [Fri, 17 Dec 2021 20:24:56 +0000 (15:24 -0500)]
ahci(4): Allow enclosure emulation without hardware.
After 53f5ac1310e allowed SATA device mapping to enclosure slots,
it may have sense to provide enclosure device emulation even without
real hardware interface like SGPIO just for purposes of physical
device location tracking (still assuming straight cabling).
Andriy Gapon [Sun, 19 Dec 2021 09:26:40 +0000 (11:26 +0200)]
twsi: fix handling of consecuitve write messages in transaction
Make sure to reset 'message_done' flag when jumping from a message to the
next one within the same interrupt handler call. This happens only when
a write with no-stop flag message is followed by a write with no-start
flag message.
Without this fix the second message would be prematurely "completed"
without waiting for an ACK (or NACK) for its first byte and without
sending subsequent bytes (if any).
Fixes: ff1e8581 twsi: support more message combinations in transfers
Doug Moore [Thu, 16 Dec 2021 18:20:56 +0000 (12:20 -0600)]
vm: Don't break vm reserv that can't meet align reqs
Function vm_reserv_test_contig has incorrectly used its alignment
and boundary parameters to find a well-positioned range of empty pages
in a reservation. Consequently, a reservation could be broken
mistakenly when it was unable to provide a satisfactory set of pages.
Rename the function, correct the errors, and add assertions to detect
the error in case it appears again.
Alexander Motin [Thu, 9 Dec 2021 02:06:11 +0000 (21:06 -0500)]
mca: Some error handling logic improvements.
- Enable local MCEs on capable Intel CPUs. It delivers exceptions
only to the affected CPU instead of global broadcast, requiring a lot
of synchronization between CPUs. AMD always deliver MCEs locally.
- Make MCE handler process only uncorrected errors, while CMCI and
polling only corrected. It reduces synchronization problems between
them and is explicitly recommended by the documentation.
- Add minimal support for uncorrected software recoverable errors
on Intel CPUs. It allows to avoid kernel panics in case uncorrected
errors do not affect current operation, like ones found during scrub
or write. Such errors are only logged, postponing the panic until
the corrupted data will actually be needed (that may never happen).
- Reduce polling period from 1 hour to 5 minutes.
Alexander Motin [Thu, 16 Dec 2021 16:44:34 +0000 (11:44 -0500)]
loader.efi: Do not use as frame buffer BLT-only GOPs.
Kernel needs physical frame buffer address and size, which Block
Transfer-only Graphics Output Protocol instances do not have.
Some recent ASUS boards like PRIME Z690M-PLUS D4 and PRIME H570-Plus
report two GOPs, out of which the second one support ConOut protocol,
that made it preferable, but is BLT-only, that made console unusable.
The e1000 drivers (em, lem, igb) are currently looking at the
iflib copies of the capabilities bitvectors (scctx->isc_capabilities
and scctx->isc_capenable) rather than the ifnet ones
(ifp->if_capabilities and ifp->if_capenable). However, the latter
are the ones that are actually updated by ifconfig and that should
be used by the drivers during interface operation. The former are
set by the driver on interface attach (for iflib internal use)
and should not be used anymore by the driver.
This patch fixes the e1000 driver to use the correct bitvectors.
Andriy Gapon [Wed, 15 Dec 2021 11:00:45 +0000 (13:00 +0200)]
rk_i2c_fill_tx: fix a number of issues
- maximum number of bytes that can be sent is 32, not 8;
- previous interface required callers to bump sc->msg->len in addition
to setting sc->tx_slave_addr;
- because of the above there was an issue with writing one too many bytes
because sc->cnt is not advanced when the slave address is written;
- the inetraction between outer and inner loops was confusing as the former
was bounded on the number of bytes to write and the counter was
incremented by one, but the inner loop advanced four bytes at a time;
- the return value was incorrect in the tx_slave_addr case; one call place
had to use its own (and incorrect in some cases) notion of the write
lenth.
All of the above issues should be fixed.
Some sanity asserts are added.
All callers use the return value to program RK_I2C_MTXCNT.
iic_msg::len no longer needs to be hacked.
A constant is added to reflect the maximum number of octets that can be
sent or received in one go (they are the same).
Andriy Gapon [Wed, 15 Dec 2021 09:11:15 +0000 (11:11 +0200)]
rk_i2c_transfer: minor improvement to bit twiddling
No need to mask a uint8_t with 0xff, the mask covers the whole type.
Explcitly cast to uint32_t before bit shifting instead of relying on
the implicit promotion to signed int.
Andriy Gapon [Wed, 15 Dec 2021 08:51:24 +0000 (10:51 +0200)]
rk_i2c: keep sending bytes until all bytes are sent
Previously the code would decalre the transfer complete after sending
first 31 bytes (plus the slave address) of a larger I2C write transfer.
That was tested using a large write to an EEPROM with 32-byte write page
size and a 2-byte address type. Such a transaction needed to send 34
bytes, 2 bytes for an offset and 32 bytes of actual data.
Cy Schubert [Sun, 12 Dec 2021 23:57:36 +0000 (15:57 -0800)]
ipfilter: Fix struct ifnet pointer type
The fr_info struct contains a summary of a packet. One of its fields
is a pointer to the ifnet struct the packet arrived on. It is pointed
to by a void* because ipfilter supports multiple O/Ses. Unfortunately
this makes it difficult it examine with DTrace. Defining fin_ifp as a
pointer to an ifnet struct makes the struct it points to using a DTrace
script possible.
Emmanuel Vadot [Wed, 1 Dec 2021 15:13:09 +0000 (16:13 +0100)]
fb: Add new FBTYPE_EFIFB
Currently the type isn't set in the fbtype struct so any userland
program that call the FBIOGTYPE ioctl will think it's a FBTYPE_SUN1BW
which is far from the truth.
No app that I found find checks the type but at least now it's correct.
Emmanuel Vadot [Wed, 1 Dec 2021 10:57:42 +0000 (11:57 +0100)]
fb: Remove some unused ioctls
6d1699583d7e added the FBIOGXINFO,FBIOMONINFO and FBIOPUTCMAPI/FBIOGETCMAPI
ioctls and said that implementation in driver will come later.
Since it was in 2001 I think we can remove this.
Emmanuel Vadot [Wed, 1 Dec 2021 10:53:03 +0000 (11:53 +0100)]
fb: Remove unused FBIOVERTICAL ioctl
Commit 6d1699583d7e added the FBIOVERTICAL ioctl and said that implementation
in driver will come later.
Since it was in 2001 I think we can remove this.
Alexander Motin [Tue, 14 Dec 2021 18:20:14 +0000 (13:20 -0500)]
isp(4): Allow more than 2 ports to read WWNs from NVRAM.
It appears at least on QLE2694L cards 3rd and 4th ports follow the
same NVRAM addressing logic as the first two. In lack of proper
documentation this guess is as good as it can be.
Ed Maste [Thu, 25 Nov 2021 18:50:03 +0000 (13:50 -0500)]
arch.7: update applicable FreeBSD versions to 12.0 and later
Information in this document is unchanged between 11.x and 12.x, but
this is intended to be a quick reference for supported architectures.
Also bump .Dd to cover recent changes including MIPS deprecation.
Andrew Turner [Mon, 22 Nov 2021 15:20:51 +0000 (15:20 +0000)]
Per-thread stack canary on arm64
With the update to llvm 13 we are able to tell the compiler it can find
the SSP canary relative to the register that holds the userspace stack
pointer. As this is unused in most of the kernel it can be used here
to point to a per-thread SSP canary.
As the kernel could be built with an old toolchain, e.g. when upgrading
from 13, add a warning that the options was enabled but the compiler
doesn't support it to both the build and kernel boot.
Discussed with: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33079
John Baldwin [Wed, 8 Dec 2021 22:25:02 +0000 (14:25 -0800)]
libmd: Only define SHA256_Transform_c when using the ARM64 ifunc.
GCC 9 doesn't define a SHA256_Transform symbol when the stub just wraps
SHA256_Transform_c resulting in an undefined symbol for
_libmd_SHA256_Transform in libmd.so.
Andrew Turner [Fri, 23 Jul 2021 09:14:03 +0000 (10:14 +0100)]
Use arm64 sha256 intrinsics in libmd
Summary:
When running on a CPU that supports the arm64 sha256 intrinsics use them
to improve perfromance of sha256 calculations.
With this changethe following improvement has been seen on an Apple M1
with FreeBS running under Parallels, with similar results on a
Neoverse-N1 r3p1.
x sha256.orig
+ sha256.arm64
+--------------------------------------------------------------------+
|++ x x|
|+++ xxx|
||A |A||
+--------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 5 3.41 3.5 3.46 3.458 0.042661458
+ 5 0.47 0.54 0.5 0.504 0.027018512
Difference at 95.0% confidence
-2.954 +/- 0.0520768
-85.4251% +/- 0.826831%
(Student's t, pooled s = 0.0357071)
Reviewed by: cem
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31284
Rick Macklem [Sat, 6 Nov 2021 20:26:43 +0000 (13:26 -0700)]
vfs: Add "ioflag" and "cred" arguments to VOP_ALLOCATE
When the NFSv4.2 server does a VOP_ALLOCATE(), it needs
the operation to be done for the RPC's credential and not
td_ucred. It also needs the writing to be done synchronously.
This patch adds "ioflag" and "cred" arguments to VOP_ALLOCATE()
and modifies vop_stdallocate() to use these arguments.
The VOP_ALLOCATE.9 man page will be patched separately.