From: Jan Glauber <jglauber@marvell.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Rafael David Tinoco <rafaeldtinoco@ubuntu.com>,
lizhengui <lizhengui@huawei.com>,
dann frazier <dann.frazier@canonical.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Bug 1805256 <1805256@bugs.launchpad.net>,
QEMU Developers - ARM <qemu-arm@nongnu.org>
Subject: Re: [Qemu-devel] qemu_futex_wait() lockups in ARM64: 2 possible issues
Date: Fri, 11 Oct 2019 06:05:25 +0000 [thread overview]
Message-ID: <20191011060518.GA6920@hc> (raw)
In-Reply-To: <d5367b2a-84ee-1211-a2dc-7d631c94fe3f@redhat.com>
On Wed, Oct 09, 2019 at 11:15:04AM +0200, Paolo Bonzini wrote:
> On 09/10/19 10:02, Jan Glauber wrote:
> > I'm still not sure what the actual issue is here, but could it be some bad
> > interaction between the notify_me and the list_lock? The are both 4 byte
> > and side-by-side:
> >
> > address notify_me: 0xaaaadb528aa0 sizeof notify_me: 4
> > address list_lock: 0xaaaadb528aa4 sizeof list_lock: 4
> >
> > AFAICS the generated code looks OK (all load/store exclusive done
> > with 32 bit size):
> >
> > e6c: 885ffc01 ldaxr w1, [x0]
> > e70: 11000821 add w1, w1, #0x2
> > e74: 8802fc01 stlxr w2, w1, [x0]
> >
> > ...but if I bump notify_me size to uint64_t the issue goes away.
>
> Ouch. :) Is this with or without my patch(es)?
>
> Also, what if you just add a dummy uint32_t after notify_me?
With the dummy the testcase also runs fine for 500 iterations.
Dann, can you try if this works on the Hi1620 too?
--Jan
next prev parent reply other threads:[~2019-10-11 6:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 2:15 [Qemu-arm] qemu_futex_wait() lockups in ARM64: 2 possible issues Rafael David Tinoco
2019-09-11 7:05 ` Rafael David Tinoco
2019-09-11 13:17 ` Paolo Bonzini
2019-09-11 14:48 ` [Qemu-devel] " Rafael David Tinoco
2019-09-11 19:09 ` [Qemu-arm] " Rafael David Tinoco
2019-09-24 20:25 ` [Qemu-devel] " dann frazier
2019-10-02 9:23 ` Jan Glauber
2019-10-02 9:45 ` Paolo Bonzini
2019-10-02 11:05 ` Jan Glauber
2019-10-02 13:20 ` memory barriers and ATOMIC_SEQ_CST on aarch64 (was Re: [Qemu-devel] qemu_futex_wait() lockups in ARM64: 2 possible issues) Paolo Bonzini
2019-10-02 14:58 ` Torvald Riegel
2019-10-02 16:30 ` Paolo Bonzini
2019-10-07 11:06 ` [Qemu-devel] qemu_futex_wait() lockups in ARM64: 2 possible issues Paolo Bonzini
2019-10-07 14:36 ` Jan Glauber
2019-10-07 14:44 ` dann frazier
2019-10-07 14:58 ` Paolo Bonzini
2019-10-09 8:02 ` Jan Glauber
2019-10-09 9:15 ` Paolo Bonzini
2019-10-11 6:05 ` Jan Glauber [this message]
2019-10-11 8:18 ` Paolo Bonzini
2019-10-11 8:30 ` Jan Glauber
2019-10-11 17:50 ` dann frazier
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=20191011060518.GA6920@hc \
--to=jglauber@marvell.com \
--cc=1805256@bugs.launchpad.net \
--cc=dann.frazier@canonical.com \
--cc=lizhengui@huawei.com \
--cc=pbonzini@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rafaeldtinoco@ubuntu.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox