hwpstate_amd(4): Fix punctuation in 'desired_performance' knob's description
To be consistent with that of the others.
No functional change.
Sponsored by: The FreeBSD Foundation
hwpstate_amd(4): CPPC: Allow attaching even if CAPABILITY_1 cannot be read
If that MSR cannot be read, we fallback to defaults specified by the
ACPI specification, as we are already doing when the minimum and maximum
values in there look bogus.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55252
cpufreq(4): cpufreq_levels_sysctl(): Remove always false NULL test
'sc->levels_buf' is initialized with malloc(M_WAITOK), so can never be
NULL. Another sysctl handler function (cpufreq_curr_sysctl()) already
relies on that.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
hwpstate_amd(4): CPPC: Switch the default to maximum performance
Set controls to maximum performance to avoid regressions now that CPPC
is activated by default and to match what the P-state support does.
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55253
hwpstate_amd(4): Consistency of cached CPPC_REQUEST value
If writing to the CPPC_REQUEST MSR fails, make sure we do not set the
softc's 'cppc.request' field to the intended new value. Both
set_cppc_request_cb() and enable_cppc_cb() were changed to this effect.
In case enable_cppc_cb() could not read CPPC_REQUEST, mark that through
a new softc flag, HWPFL_CPPC_REQUEST_NOT_READ, so that we do not keep
and use a wrong value when the content of CPPC_REQUEST is read/written
through sysctl(9) knobs, but instead retry reading the MSR (this is the
purpose of the new get_cppc_request() sub-function).
When setting CPPC_REQUEST has failed, distinguish the case where it
could not be read at all from the case where it could not be written, by
respectively returning EIO and EOPNOTSUPP in these cases. The previous
return value of EFAULT was confusing as sysctl(3) documents it as
happening if the passed arguments are invalid.
While here, add some herald comment before sysctl_cppc_dump_handler()
[5 lines not shown]
chore: asmc: use designated initializers in macros
This code cleanup makes it easier for human readers to understand what each
of the fields actually represents, as well as makes it easier to modify
what the macros actually do under the covers, without introducing
potential human errors.
No functional change intended.
MFC after: 1 week
asmc: use symbolic names with the MacPro3,1 model
Use `ASMC_LIGHT_FUNCS_DISABLED` and `ASMC_SMS_FUNCS_DISABLED` instead of
the unrolled versions of the macros.
This makes it easier to adjust the underlying macros/fields for
`struct asmc_model`.
No functional change intended.
MFC after: 1 week
asmc: use `ASMC_FAN_FUNCS2` with the Macmini4,1
The Macmini4,1 model does not have "fansafespeed" support. This issue
typically manifests with messages like so:
```
asmc0: asmc_key_read for key F0Sf failed 10 times, giving up
```
Swap out `ASMC_FAN_FUNCS` with `ASMC_FAN_FUNCS2` to explicitly drop
"fansafespeed" checks in the driver for the model as it doesn't support
that hardware feature.
MFC after: 1 week
Reported by: @probonopd
Closes: https://github.com/helloSystem/ISO/issues/357
ipfilter: Interface name must not extend beyond end of buffer
sifpidx (an interface name) cannot extend beyond the end of the
fr_names buffer.
We do the validation for fr_sifpidx here because it is a union that
contains an offset only when fr_sifpidx points to an interface name,
an offset into fr_names. The union is an offset into fr_names in this
case only.
interr_tbl now becomes a static variable outside a function to facilitate
its use by two functions within fil.c
Note that sifpidx is only used in ipf_sync() which implments ipf -y.
Reported by: Ilja Van Sprundel <ivansprundel at ioactive.com>
MFC after: 1 week
(cherry picked from commit 47fb51847fdea3f1cce841b5f2bbbcd6f8a04ee0)
ipfilter: Fix possible overrun
The destination buffer is FR_GROUPLEN (16 bytes) in length. When
gname is created, the userspace utilities correctly use FR_GROUPLEN
as the buffer length. The kernel should also limit its copy operation to
FR_GROUPLEN bytes to avoid any user written code from exploiting this
vulnerability.
Reported by: Ilja Van Sprundel <ivansprundel at ioactive.com>
(cherry picked from commit e40817302ebdf89df2f3bcd679fb7f2a18c244dc)
bhyve: fix USB mouse requests
USB HCI requests may not include HCI transfer block structures (i.e.,
xfer->data[] == NULL), but in several places, the USB mouse emulation
code assumes one will exist. This can lead to a NULL pointer dereference
and a SEGV in the bhyve process as observed via experiments with an
Ubuntu guest and PyUSB code. Note that many of the cases processing
other request types already checked for data == NULL.
While in the neighborhood, fix a typo in the loop iterating over the
usb_data_xfer_block array which used the wrong variable to check for
valid data (idx vs. i).
Reported by: danmcd at edgecast.io
Obtained from: SmartOS
MFC after: 1 week
Relnotes: yes
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D54661
bhyve: Fix unchecked stream I/O in RFB handler
Convert rfb_send_* helpers to return status codes and check their
results. Add missing checks for stream_read() and stream_write() returns
during the handshake in rfb_handle() to avoid acting on failed I/O.
Signed-off-by: Hayzam Sherif <hayzam at gmail.com>
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55343
