Signed-off-by: Stefan Bader <email address hidden>
af26583...
by
Ross Lagerwall <email address hidden>
xen-netfront: Update features after registering netdev
Update the features after calling register_netdev() otherwise the
device features are not set up correctly and it not possible to change
the MTU of the device. After this change, the features reported by
ethtool match the device's features before the commit which introduced
the issue and it is possible to change the device's MTU.
Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open")
Reported-by: Liam Shepherd <email address hidden>
Signed-off-by: Ross Lagerwall <email address hidden>
Reviewed-by: Juergen Gross <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 45c8184c1bed1ca8a7f02918552063a00b909bf5)
Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Khaled Elmously <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
758c626...
by
Ross Lagerwall <email address hidden>
xen-netfront: Fix mismatched rtnl_unlock
Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open")
Reported-by: Ben Hutchings <email address hidden>
Signed-off-by: Ross Lagerwall <email address hidden>
Reviewed-by: Juergen Gross <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit cb257783c2927b73614b20f915a91ff78aa6f3e8)
Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Khaled Elmously <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
444dd40...
by
Borislav Petkov <email address hidden>
x86/fpu: Fix eager-FPU handling on legacy FPU machines
i486 derived cores like Intel Quark support only the very old,
legacy x87 FPU (FSAVE/FRSTOR, CPUID bit FXSR is not set), and
our FPU code wasn't handling the saving and restoring there
properly in the 'eagerfpu' case.
So after we made eagerfpu the default for all CPU types:
58122bf1d856 x86/fpu: Default eagerfpu=on on all CPUs
these old FPU designs broke. First, Andy Shevchenko reported a splat:
WARNING: CPU: 0 PID: 823 at arch/x86/include/asm/fpu/internal.h:163 fpu__clear+0x8c/0x160
which was us trying to execute FXRSTOR on those machines even though
they don't support it.
After taking care of that, Bryan O'Donoghue reported that a simple FPU
test still failed because we weren't initializing the FPU state properly
on those machines.
(cherry picked from commit 6e6867093de35141f0a76b66ac13f9f2e2c8e77a)
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
8e3790d...
by
Andy Lutomirski <email address hidden>
x86/fpu: Fix math emulation in eager fpu mode
Systems without an FPU are generally old and therefore use lazy FPU
switching. Unsurprisingly, math emulation in eager FPU mode is a
bit buggy. Fix it.
There were two bugs involving kernel code trying to use the FPU
registers in eager mode even if they didn't exist and one BUG_ON()
that was incorrect.
(cherry picked from commit 4ecd16ec7059390b430af34bd8bc3ca2b5dcef9a)
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
0e12511...
by
Andy Lutomirski <email address hidden>
x86/fpu: Fix FNSAVE usage in eagerfpu mode
In eager fpu mode, having deactivated FPU without immediately
reloading some other context is illegal. Therefore, to recover from
FNSAVE, we can't just deactivate the state -- we need to reload it
if we're not actively context switching.
We had this wrong in fpu__save() and fpu__copy(). Fix both.
__kernel_fpu_begin() was fine -- add a comment.
This fixes a warning triggerable with nofxsr eagerfpu=on.
(cherry picked from commit 5ed73f40735c68d8a656b46d09b1885d3b8740ae)
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
5982a1a...
by
Andy Lutomirski <email address hidden>
x86/fpu: Default eagerfpu=on on all CPUs
We have eager and lazy FPU modes, introduced in:
304bceda6a18 ("x86, fpu: use non-lazy fpu restore for processors supporting xsave")
The result is rather messy. There are two code paths in almost all
of the FPU code, and only one of them (the eager case) is tested
frequently, since most kernel developers have new enough hardware
that we use eagerfpu.
It seems that, on any remotely recent hardware, eagerfpu is a win:
glibc uses SSE2, so laziness is probably overoptimistic, and, in any
case, manipulating TS is far slower that saving and restoring the
full state. (Stores to CR0.TS are serializing and are poorly
optimized.)
To try to shake out any latent issues on old hardware, this changes
the default to eager on all CPUs. If no performance or functionality
problems show up, a subsequent patch could remove lazy mode entirely.
This issue is a fallout from the command-line parsing move.
When "eagerfpu=off" is given as a command-line input, the kernel
should disable MPX support. The decision for turning off MPX was
made in fpu__init_system_ctx_switch(), which is after the
selection of the XSAVE format. This patch fixes it by getting
that decision done earlier in fpu__init_system_xstate().
