From: Paolo Bonzini <pbonzini@redhat.com>
To: Boqun Feng <boqun.feng@gmail.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org
Subject: Re: [PATCH] kvm/x86: Handle async PF in RCU read-side critical sections
Date: Fri, 29 Sep 2017 16:53:57 +0200 [thread overview]
Message-ID: <95ecfeff-093d-4438-dbcb-ecc81abca993@redhat.com> (raw)
In-Reply-To: <20170929110148.3467-1-boqun.feng@gmail.com>
On 29/09/2017 13:01, Boqun Feng wrote:
> Sasha Levin reported a WARNING:
>
> | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329
> | rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline]
> | WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329
> | rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458
> ...
> | CPU: 0 PID: 6974 Comm: syz-fuzzer Not tainted 4.13.0-next-20170908+ #246
> | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> | 1.10.1-1ubuntu1 04/01/2014
> | Call Trace:
> ...
> | RIP: 0010:rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline]
> | RIP: 0010:rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458
> | RSP: 0018:ffff88003b2debc8 EFLAGS: 00010002
> | RAX: 0000000000000001 RBX: 1ffff1000765bd85 RCX: 0000000000000000
> | RDX: 1ffff100075d7882 RSI: ffffffffb5c7da20 RDI: ffff88003aebc410
> | RBP: ffff88003b2def30 R08: dffffc0000000000 R09: 0000000000000001
> | R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003b2def08
> | R13: 0000000000000000 R14: ffff88003aebc040 R15: ffff88003aebc040
> | __schedule+0x201/0x2240 kernel/sched/core.c:3292
> | schedule+0x113/0x460 kernel/sched/core.c:3421
> | kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158
> | do_async_page_fault+0x72/0x90 arch/x86/kernel/kvm.c:271
> | async_page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1069
> | RIP: 0010:format_decode+0x240/0x830 lib/vsprintf.c:1996
> | RSP: 0018:ffff88003b2df520 EFLAGS: 00010283
> | RAX: 000000000000003f RBX: ffffffffb5d1e141 RCX: ffff88003b2df670
> | RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffb5d1e140
> | RBP: ffff88003b2df560 R08: dffffc0000000000 R09: 0000000000000000
> | R10: ffff88003b2df718 R11: 0000000000000000 R12: ffff88003b2df5d8
> | R13: 0000000000000064 R14: ffffffffb5d1e140 R15: 0000000000000000
> | vsnprintf+0x173/0x1700 lib/vsprintf.c:2136
> | sprintf+0xbe/0xf0 lib/vsprintf.c:2386
> | proc_self_get_link+0xfb/0x1c0 fs/proc/self.c:23
> | get_link fs/namei.c:1047 [inline]
> | link_path_walk+0x1041/0x1490 fs/namei.c:2127
> ...
>
> And this happened when we hit a page fault in an RCU read-side critical
> section and then we tried to reschedule in kvm_async_pf_task_wait(),
> this reschedule would hit the WARN in rcu_preempt_note_context_switch(),
> and be treated as a sleep in RCU read-side critical section, which is
> not allowed(even in preemptible RCU).
Just a small fix to the commit message:
This happened when the host hit a page fault, and delivered it as in an
async page fault, while the guest was in an RCU read-side critical
section. The guest then tries to reschedule in kvm_async_pf_task_wait(),
but rcu_preempt_note_context_switch() would treat the reschedule as a
sleep in RCU read-side critical section, which is not allowed (even in
preemptible RCU). Thus the WARN.
Queued with that change, thanks.
Paolo
> To cure this, make kvm_async_pf_task_wait() go to the halt path if the
> PF happens in a RCU read-side critical section.
>
> Reported-by: Sasha Levin <levinsasha928@gmail.com>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> ---
> arch/x86/kernel/kvm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index aa60a08b65b1..e675704fa6f7 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -140,7 +140,8 @@ void kvm_async_pf_task_wait(u32 token)
>
> n.token = token;
> n.cpu = smp_processor_id();
> - n.halted = is_idle_task(current) || preempt_count() > 1;
> + n.halted = is_idle_task(current) || preempt_count() > 1 ||
> + rcu_preempt_depth();
> init_swait_queue_head(&n.wq);
> hlist_add_head(&n.link, &b->list);
> raw_spin_unlock(&b->lock);
>
next prev parent reply other threads:[~2017-09-29 14:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-29 11:01 [PATCH] kvm/x86: Handle async PF in RCU read-side critical sections Boqun Feng
2017-09-29 14:53 ` Paolo Bonzini [this message]
2017-09-29 16:43 ` Paul E. McKenney
2017-09-29 23:41 ` Boqun Feng
2017-09-30 17:15 ` Paul E. McKenney
2017-10-01 1:20 ` Boqun Feng
2017-10-02 12:45 ` Paolo Bonzini
2017-10-02 13:53 ` Paul E. McKenney
2017-10-01 1:31 ` [PATCH v2] " Boqun Feng
2017-10-02 13:41 ` Paolo Bonzini
2017-10-02 14:43 ` Boqun Feng
2017-10-02 15:34 ` Paul E. McKenney
2017-10-02 21:11 ` Paolo Bonzini
2017-10-02 21:41 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95ecfeff-093d-4438-dbcb-ecc81abca993@redhat.com \
--to=pbonzini@redhat.com \
--cc=boqun.feng@gmail.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.