Old, circa 2002 chipsets have a bug: they don't go idle when they are
supposed to. So, a workaround was added to slow the CPU down and
ensure that the CPU waits a bit for the chipset to actually go idle.
This workaround is ancient and has been in place in some form since
the original kernel ACPI implementation.
But, this workaround is very painful on modern systems. The "inl()"
can take thousands of cycles (see Link: for some more detailed
numbers and some fun kernel archaeology).
First and foremost, modern systems should not be using this code.
Typical Intel systems have not used it in over a decade because it is
horribly inferior to MWAIT-based idle.
Despite this, people do seem to be tripping over this workaround on
AMD system today.
Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD
systems from tripping over the workaround. Remotely modern Intel
systems use intel_idle instead of this code and will, in practice,
remain unaffected by the dummy wait.
Reported-by: K Prateek Nayak <email address hidden>
Suggested-by: Rafael J. Wysocki <email address hidden>
Signed-off-by: Dave Hansen <email address hidden>
Reviewed-by: Mario Limonciello <email address hidden>
Tested-by: K Prateek Nayak <email address hidden>
Link: https://<email address hidden>/
Link: https://<email address hidden>
(cherry picked from commit e400ad8b7e6a1b9102123c6240289a811501f7d9)
Signed-off-by: Jeff Lane <email address hidden>
In function acpi_idle_do_entry(), an ioport access is used for
dummy wait to guarantee hardware behavior. But it could trigger
unnecessary VMexit if kernel is running as guest in virtualization
environment.
If it's in virtualization environment, the deeper C state enter
operation (inb()) will trap to hypervisor. It's not needed to do
dummy wait after the inb() call. So we could just remove the
dummy io port access to avoid unnecessary VMexit.
And keep dummy io port access to maintain timing for native
environment.
Signed-off-by: Yin Fengwei <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit fa583f71a99c85e52781ed877c82c8757437b680)
Signed-off-by: Jeff Lane <email address hidden>
001edf9...
by
Pavel Begunkov <email address hidden>
io_uring: disable polling pollfree files
Older kernels lack io_uring POLLFREE handling. As only affected files
are signalfd and android binder the safest option would be to disable
polling those files via io_uring and hope there are no users.
Fixes: 221c5eb233823 ("io_uring: add support for IORING_OP_POLL")
Signed-off-by: Pavel Begunkov <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
CVE-2022-3176
(cherry picked from commit fc78b2fc21f10c4c9c4d5d659a685710ffa63659 linux-5.4.y)
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
This test implement the scenario described in the commit
"ip: fix dflt addr selection for connected nexthop".
The test configures a nexthop object with an output device only (no gateway
address) and a route that uses this nexthop. The goal is to check if the
kernel selects a valid source address.
(backported from commit cd72e61bad145a0968df85193dcf1261cb66c4c6)
[lukenow: minor context adjustments in makefile]
Signed-off-by: Luke Nowakowski-Krijger <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
__mkroute_input() uses fib_validate_source() to trigger an icmp redirect.
My understanding is that fib_validate_source() is used to know if the src
address and the gateway address are on the same link. For that,
fib_validate_source() returns 1 (same link) or 0 (not the same network).
__mkroute_input() is the only user of these positive values, all other
callers only look if the returned value is negative.
Since the below patch, fib_validate_source() didn't return anymore 1 when
both addresses are on the same network, because the route lookup returns
RT_SCOPE_LINK instead of RT_SCOPE_HOST. But this is, in fact, right.
Let's adapat the test to return 1 again when both addresses are on the same
link.
