ufshci: Enable admin command retry
Also, This patch fixes an issue where the admin command flag was not
passed through.
Sponsored by: Samsung Electronic
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D54244
vm/vm_object.h: clarify the OBJ_ONEMAPPING semantic
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D54459
libc/amd64: fix stpncpy.S again
The previous fix introduced a regression on machines without the BMI1
instruction set extension. The TZCNT instruction used in this function
behaves different on old machines when the source operand is zero, but
the code was originally designed to never trigger this case. The bug
fix caused this case to be possible, leading to a regression on
sufficiently old hardware.
Fix the code by messing with things such that the source operand is
never zero.
PR: 291720
Fixes: 66eb78377bf109af1d9e25626bf254b4369436ec
Tested by: cy
Approved by: markj (mentor)
Differential Revision: https://reviews.freebsd.org/D54303
(cherry picked from commit 2f83319214d9adb8ab7a77e35d1014658b3f9cae)
libc/amd64: fix overread conditions in stpncpy()
Due to incorrect unit test design, two overread conditions went
undetected in the amd64 baseline stpncpy() implementation.
For buffers of 1--16 and 32 bytes that do not contain nul bytes
and end exactly at a page boundary, the code would incorrectly
read 16 bytes from the next page, possibly crossing into an
unmapped page and crashing the program. If the next page was
mapped, the code would then proceed with the expected behaviour
of the stpncpy() function.
Three changes were made to fix the bug:
- an off-by-one error is fixed in the code deciding whether to
enter the runt case or not, entering it for 0<n<=32 bytes
instead of 0<n<32 bytes as it was before.
- in the runt case, the logic to skip reading a second 16-byte
chunk if the buffer ends in the first chunk was fixed to
account for buffers that end at a 16-byte boundary but do not
[18 lines not shown]
libc/amd64: Disable baseline version of stpncpy()
This implementation appears to be broken on some CPUs. Disable it
until the issue can be investigated and fixed.
PR: 291720
Fixes: 66eb78377bf1 ("libc/amd64: fix overread conditions in stpncpy()")
Fixes: 90253d49db09 ("lib/libc/amd64/string: add stpncpy scalar, baseline implementation")
(cherry picked from commit ce9557d4ee174267504a63b2c8f6009be27368c9)
libc/amd64: fix stpncpy.S again
The previous fix introduced a regression on machines without the BMI1
instruction set extension. The TZCNT instruction used in this function
behaves different on old machines when the source operand is zero, but
the code was originally designed to never trigger this case. The bug
fix caused this case to be possible, leading to a regression on
sufficiently old hardware.
Fix the code by messing with things such that the source operand is
never zero.
PR: 291720
Fixes: 66eb78377bf109af1d9e25626bf254b4369436ec
Tested by: cy
Approved by: markj (mentor)
Differential Revision: https://reviews.freebsd.org/D54303
(cherry picked from commit 2f83319214d9adb8ab7a77e35d1014658b3f9cae)
libc/amd64: fix overread conditions in stpncpy()
Due to incorrect unit test design, two overread conditions went
undetected in the amd64 baseline stpncpy() implementation.
For buffers of 1--16 and 32 bytes that do not contain nul bytes
and end exactly at a page boundary, the code would incorrectly
read 16 bytes from the next page, possibly crossing into an
unmapped page and crashing the program. If the next page was
mapped, the code would then proceed with the expected behaviour
of the stpncpy() function.
Three changes were made to fix the bug:
- an off-by-one error is fixed in the code deciding whether to
enter the runt case or not, entering it for 0<n<=32 bytes
instead of 0<n<32 bytes as it was before.
- in the runt case, the logic to skip reading a second 16-byte
chunk if the buffer ends in the first chunk was fixed to
account for buffers that end at a 16-byte boundary but do not
[18 lines not shown]
libc/amd64: Disable baseline version of stpncpy()
This implementation appears to be broken on some CPUs. Disable it
until the issue can be investigated and fixed.
PR: 291720
Fixes: 66eb78377bf1 ("libc/amd64: fix overread conditions in stpncpy()")
Fixes: 90253d49db09 ("lib/libc/amd64/string: add stpncpy scalar, baseline implementation")
(cherry picked from commit ce9557d4ee174267504a63b2c8f6009be27368c9)
libc/amd64: fix stpncpy.S again
The previous fix introduced a regression on machines without the BMI1
instruction set extension. The TZCNT instruction used in this function
behaves different on old machines when the source operand is zero, but
the code was originally designed to never trigger this case. The bug
fix caused this case to be possible, leading to a regression on
sufficiently old hardware.
Fix the code by messing with things such that the source operand is
never zero.
PR: 291720
Fixes: 66eb78377bf109af1d9e25626bf254b4369436ec
Tested by: cy
Approved by: markj (mentor)
Differential Revision: https://reviews.freebsd.org/D54303
loader.efi: only use firmware provided Blt on GOP
gfx_state.tg_private points to a EFI_GRAPHICS_OUTPUT_PROTOCOL only when
using GOP.
The firmware provided Blt functions on UGA platforms have been observed
to not work on old MacBooks, and are likley hit or miss anyways as UGA
has been deprecated since 2006.
Reviewed by: tsoome
PR: 291935
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54432
loader.efi: probe for UGA if GOP isn't found
Probe for UGA instead of returning early if we can't find GOP.
Reviewed by: tsoome
PR: 291935
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54431
bhyvectl: improve options error handling
Currently, it is possible to execute bhyvectl(8) with mutually exclusive
options, such as "--destroy" and "--suspend", and it will print out
obscure errors, e.g.:
bhyvectl --suspend=/var/run/vms/my_vm --destroy --vm my_vm
connect() failed: Connection refused
Address that by failing early if mutually exclusive options were
specified.
Additionally, move the BHYVE_SNAPSHOT block before the errors are
printed, so its errors are also displayed.
Approved by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D54092
[2 lines not shown]
bhyve: change suspend exit code
Currently, after suspending, bhyve(8) exits with 0. This code is
also used to indicate that a VM was rebooted. To differentiate
reboot and suspend, use the next available exit code, 5, for suspend.
Approved by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D54087
(cherry picked from commit 611bbb190ff593e0e424e311575d7e978e623659)
