From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
cota@braap.org, richard.henderson@linaro.org
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] establish nesting rule of BQL vs cpu-exclusive
Date: Thu, 23 May 2019 12:31:16 +0100 [thread overview]
Message-ID: <87imu11k6z.fsf@zen.linaroharston> (raw)
In-Reply-To: <20190523105440.27045-1-rkagan@virtuozzo.com>
Roman Kagan <rkagan@virtuozzo.com> writes:
> I came across the following AB-BA deadlock:
>
> vCPU thread main thread
> ----------- -----------
> async_safe_run_on_cpu(self,
> async_synic_update)
> ... [cpu hot-add]
> process_queued_cpu_work()
> qemu_mutex_unlock_iothread()
> [grab BQL]
> start_exclusive() cpu_list_add()
> async_synic_update() finish_safe_work()
> qemu_mutex_lock_iothread() cpu_exec_start()
>
> ATM async_synic_update seems to be the only async safe work item that
> grabs BQL. However it isn't quite obvious that it shouldn't; in the
> past there were more examples of this (e.g.
> memory_region_do_invalidate_mmio_ptr).
>
> It looks like the problem is generally in the lack of the nesting rule
> for cpu-exclusive sections against BQL, so I thought I would try to
> address that. This patchset is my feeble attempt at this; I'm not sure
> I fully comprehend all the consequences (rather, I'm sure I don't) hence
> RFC.
Hmm I think this is an area touched by:
Subject: [PATCH v7 00/73] per-CPU locks
Date: Mon, 4 Mar 2019 13:17:00 -0500
Message-Id: <20190304181813.8075-1-cota@braap.org>
which has stalled on it's path into the tree. Last time I checked it
explicitly handled the concept of work that needed the BQL and work that
didn't.
How do you trigger your deadlock? Just hot-pluging CPUs?
>
> Roman Kagan (2):
> cpus-common: nuke finish_safe_work
> cpus-common: assert BQL nesting within cpu-exclusive sections
>
> cpus-common.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
--
Alex Bennée
next prev parent reply other threads:[~2019-05-23 11:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 10:54 [Qemu-devel] [RFC PATCH 0/2] establish nesting rule of BQL vs cpu-exclusive Roman Kagan
2019-05-23 10:54 ` [Qemu-devel] [RFC PATCH 1/2] cpus-common: nuke finish_safe_work Roman Kagan
2019-06-24 10:58 ` Alex Bennée
2019-06-24 11:50 ` Roman Kagan
2019-06-24 12:43 ` Alex Bennée
2019-05-23 10:54 ` [Qemu-devel] [RFC PATCH 2/2] cpus-common: assert BQL nesting within cpu-exclusive sections Roman Kagan
2019-05-23 11:31 ` Alex Bennée [this message]
2019-05-27 11:05 ` [Qemu-devel] [RFC PATCH 0/2] establish nesting rule of BQL vs cpu-exclusive Roman Kagan
2019-06-06 13:22 ` Roman Kagan
2019-06-21 12:49 ` Roman Kagan
2019-08-05 12:47 ` Roman Kagan
2019-08-05 15:56 ` Paolo Bonzini
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=87imu11k6z.fsf@zen.linaroharston \
--to=alex.bennee@linaro.org \
--cc=cota@braap.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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.