linux-toradex.git/arch/x86, branch v4.4.5

PM / sleep / x86: Fix crash on graph trace through x86 suspend

2016-03-09T23:34:52+00:00

commit 92f9e179a702a6adbc11e2fedc76ecd6ffc9e3f7 upstream.

Pause/unpause graph tracing around do_suspend_lowlevel as it has
inconsistent call/return info after it jumps to the wakeup vector.
The graph trace buffer will otherwise become misaligned and
may eventually crash and hang on suspend.

To reproduce the issue and test the fix:
Run a function_graph trace over suspend/resume and set the graph
function to suspend_devices_and_enter. This consistently hangs the
system without this fix.

Signed-off-by: Todd Brandt 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: fix root cause for missed hardware breakpoints

2016-03-09T23:34:50+00:00

commit 70e4da7a8ff62f2775337b705f45c804bb450454 upstream.

Commit 172b2386ed16 ("KVM: x86: fix missed hardware breakpoints",
2016-02-10) worked around a case where the debug registers are not loaded
correctly on preemption and on the first entry to KVM_RUN.

However, Xiao Guangrong pointed out that the root cause must be that
KVM_DEBUGREG_BP_ENABLED is not being set correctly.  This can indeed
happen due to the lazy debug exit mechanism, which does not call
kvm_update_dr7.  Fix it by replacing the existing loop (more or less
equivalent to kvm_update_dr0123) with calls to all the kvm_update_dr*
functions.

Fixes: 172b2386ed16a9143d9a456aae5ec87275c61489
Reviewed-by: Xiao Guangrong 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

kvm: x86: Update tsc multiplier on change.

2016-03-09T23:34:50+00:00

commit 2680d6da455b636dd006636780c0f235c6561d70 upstream.

vmx.c writes the TSC_MULTIPLIER field in vmx_vcpu_load, but only when a
vcpu has migrated physical cpus. Record the last value written and
update in vmx_vcpu_load on any change, otherwise a cpu migration must
occur for TSC frequency scaling to take effect.

Fixes: ff2c3a1803775cc72dc6f624b59554956396b0ee
Signed-off-by: Owen Hofmann 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

x86/irq: Plug vector cleanup race

2016-03-03T23:07:32+00:00

commit 98229aa36caa9c769b13565523de9b813013c703 upstream.

We still can end up with a stale vector due to the following:

CPU0                          CPU1                      CPU2
lock_vector()
data->move_in_progress=0
sendIPI()
unlock_vector()
                              set_affinity()
                              assign_irq_vector()
                              lock_vector()             handle_IPI
                              move_in_progress = 1      lock_vector()
                              unlock_vector()
                                                        move_in_progress == 1

So we need to serialize the vector assignment against a pending cleanup. The
solution is rather simple now. We not only check for the move_in_progress flag
in assign_irq_vector(), we also check whether there is still a cleanup pending
in the old_domain cpumask. If so, we return -EBUSY to the caller and let him
deal with it. Though we have to be careful in the cpu unplug case. If the
cleanout has not yet completed then the following setaffinity() call would
return -EBUSY. Add code which prevents this.

Full context is here: http://lkml.kernel.org/r/5653B688.4050809@stratus.com

Reported-and-tested-by: Joe Lawrence 
Signed-off-by: Thomas Gleixner 
Tested-by: Borislav Petkov 
Cc: Jiang Liu 
Cc: Jeremiah Mahler 
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20151231160107.207265407@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/irq: Call irq_force_move_complete with irq descriptor

2016-03-03T23:07:31+00:00

commit 90a2282e23f0522e4b3f797ad447c5e91bf7fe32 upstream.

First of all there is no point in looking up the irq descriptor again, but we
also need the descriptor for the final cleanup race fix in the next
patch. Make that change seperate. No functional difference.

Signed-off-by: Thomas Gleixner 
Tested-by: Borislav Petkov 
Tested-by: Joe Lawrence 
Cc: Jiang Liu 
Cc: Jeremiah Mahler 
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20151231160107.125211743@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/irq: Remove outgoing CPU from vector cleanup mask

2016-03-03T23:07:31+00:00

commit 56d7d2f4bbd00fb198b7907cb3ab657d06115a42 upstream.

We want to synchronize new vector assignments with a pending cleanup. Remove a
dying cpu from a pending cleanup mask.

Signed-off-by: Thomas Gleixner 
Tested-by: Borislav Petkov 
Tested-by: Joe Lawrence 
Cc: Jiang Liu 
Cc: Jeremiah Mahler 
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20151231160107.045961667@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/irq: Remove the cpumask allocation from send_cleanup_vector()

2016-03-03T23:07:31+00:00

commit 5da0c1217f05d2ccc9a8ed6e6e5c23a8a1d24dd6 upstream.

There is no need to allocate a new cpumask for sending the cleanup vector. The
old_domain mask is now protected by the vector_lock, so we can safely remove
the offline cpus from it and send the IPI with the resulting mask.

Signed-off-by: Thomas Gleixner 
Tested-by: Borislav Petkov 
Tested-by: Joe Lawrence 
Cc: Jiang Liu 
Cc: Jeremiah Mahler 
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20151231160106.967993932@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/irq: Clear move_in_progress before sending cleanup IPI

2016-03-03T23:07:31+00:00

commit c1684f5035b60e9f98566493e869496fb5de1d89 upstream.

send_cleanup_vector() fiddles with the old_domain mask unprotected because it
relies on the protection by the move_in_progress flag. But this is fatal, as
the flag is reset after the IPI has been sent. So a cpu which receives the IPI
can still see the flag set and therefor ignores the cleanup request. If no
other cleanup request happens then the vector stays stale on that cpu and in
case of an irq removal the vector still persists. That can lead to use after
free when the next cleanup IPI happens.

Protect the code with vector_lock and clear move_in_progress before sending
the IPI.

This does not plug the race which Joe reported because:

CPU0                          CPU1                      CPU2
lock_vector()
data->move_in_progress=0
sendIPI()
unlock_vector()
                              set_affinity()
                              assign_irq_vector()
                              lock_vector()             handle_IPI
                              move_in_progress = 1      lock_vector()
                              unlock_vector()
                                                        move_in_progress == 1

The full fix comes with a later patch.

Reported-and-tested-by: Joe Lawrence 
Signed-off-by: Thomas Gleixner 
Tested-by: Borislav Petkov 
Cc: Jiang Liu 
Cc: Jeremiah Mahler 
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20151231160106.892412198@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/irq: Remove offline cpus from vector cleanup

2016-03-03T23:07:31+00:00

commit 847667ef10356b824a11c853fc8a8b1b437b6a8d upstream.

No point of keeping offline cpus in the cleanup mask.

Signed-off-by: Thomas Gleixner 
Tested-by: Borislav Petkov 
Tested-by: Joe Lawrence 
Cc: Jiang Liu 
Cc: Jeremiah Mahler 
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20151231160106.808642683@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/irq: Get rid of code duplication

2016-03-03T23:07:31+00:00

commit ab25ac02148b600e645f77cfb8b8ea415ed75bb4 upstream.

Reusing an existing vector and assigning a new vector has duplicated
code. Consolidate it.

This is also a preparatory patch for finally plugging the cleanup race.

Signed-off-by: Thomas Gleixner 
Tested-by: Borislav Petkov 
Tested-by: Joe Lawrence 
Cc: Jiang Liu 
Cc: Jeremiah Mahler 
Cc: andy.shevchenko@gmail.com
Cc: Guenter Roeck 
Link: http://lkml.kernel.org/r/20151231160106.721599216@linutronix.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman