diff options
author | Boqun Feng <boqun.feng@gmail.com> | 2017-10-03 21:36:51 +0800 |
---|---|---|
committer | Radim Krčmář <rkrcmar@redhat.com> | 2017-10-04 18:28:53 +0200 |
commit | a2b7861bb33b2538420bb5d8554153484d3f961f (patch) | |
tree | 3d2b1e460e56ecb7155d73e6482ad4908d95248e /arch/x86/crypto/sha512_ssse3_glue.c | |
parent | 2fb1e946450a4fef74bb72f360555f7760d816f0 (diff) |
kvm/x86: Avoid async PF preempting the kernel incorrectly
Currently, in PREEMPT_COUNT=n kernel, kvm_async_pf_task_wait() could call
schedule() to reschedule in some cases. This could result in
accidentally ending the current RCU read-side critical section early,
causing random memory corruption in the guest, or otherwise preempting
the currently running task inside between preempt_disable and
preempt_enable.
The difficulty to handle this well is because we don't know whether an
async PF delivered in a preemptible section or RCU read-side critical section
for PREEMPT_COUNT=n, since preempt_disable()/enable() and rcu_read_lock/unlock()
are both no-ops in that case.
To cure this, we treat any async PF interrupting a kernel context as one
that cannot be preempted, preventing kvm_async_pf_task_wait() from choosing
the schedule() path in that case.
To do so, a second parameter for kvm_async_pf_task_wait() is introduced,
so that we know whether it's called from a context interrupting the
kernel, and the parameter is set properly in all the callsites.
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Diffstat (limited to 'arch/x86/crypto/sha512_ssse3_glue.c')
0 files changed, 0 insertions, 0 deletions