From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] memory: unregister AddressSpace MemoryListener within BQL
Date: Wed, 11 Feb 2015 07:16:41 -0600 [thread overview]
Message-ID: <20150211131641.3809.42730@loki> (raw)
In-Reply-To: <54DB04F8.3080405@redhat.com>
Quoting Paolo Bonzini (2015-02-11 01:30:00)
> On 11/02/2015 06:13, Michael Roth wrote:
> > (gdb) print node
> > $1 = (struct rcu_head *) 0x11189a68
> > (gdb) print node->func
> > $2 = (RCUCBFunc *) 0x0
> > (gdb) print node->next
> > $3 = (struct rcu_head *) 0x3fff9800d4f0
> >
> > I've seen it on both x86 and pseries (with spapr hotplug patches applied), and
> > have only seen it occur at this spot.
> >
> > AFAICT node->func is only set via 1 of:
> >
> > call_rcu(old_view, flatview_unref, rcu);
> > call_rcu(as, do_address_space_destroy, rcu);
> >
> > so it shouldn't ever be NULL... and there's a wmb after node->func is set,
> > prior to the node being made available to the RCU thread via enqueue(), so
> > that doesn't seem to be the issue.
> >
> > I think the node in this case is a FlatView*, if that helps narrow it down:
> >
> > (gdb) print ((AddressSpace *)(0x3fff9800d4f0))->name
> > $5 = 0x100000000 <Address 0x100000000 out of bounds>
>
> This is node->next, not node. The weird address looks almost like node
> == &dummy. I'll try to reproduce.
Doh, sorry, not sure why I started looking at that address. node looks to be an
AddressSpace* by way of do_pci_register_device():
(gdb) print node
$21 = (struct rcu_head *) 0x11189a68
(gdb) print ((PCIDevice *)(0x11189860))->name
$22 = "virtio-net-pci", '\000' <repeats 49 times>
(gdb) print ((AddressSpace *)(node))->root->name
$13 = 0x1117a410 "bus master"
(gdb) print ((PCIDevice *)(0x11189860))->devfn
$23 = 64
Is this state unexpected?
(gdb) print ((DeviceState *)(0x11189860))->realized
$24 = true
(gdb) print ((Object *)(0x11189860))->ref
$25 = 4
(gdb)
Since the AddressSpace is a fields of PCIDevice, do we maybe need to make
sure it's refcount doesn't drop to 0 prior to the RCU callback taking
place?
>
> Paolo
next prev parent reply other threads:[~2015-02-11 13:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 12:52 [Qemu-devel] [PATCH] memory: unregister AddressSpace MemoryListener within BQL Paolo Bonzini
2015-02-10 17:11 ` Alex Williamson
2015-02-10 17:13 ` Paolo Bonzini
2015-02-10 17:19 ` Alex Williamson
2015-02-11 5:13 ` Michael Roth
2015-02-11 7:30 ` Paolo Bonzini
2015-02-11 13:16 ` Michael Roth [this message]
2015-02-11 13:26 ` 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=20150211131641.3809.42730@loki \
--to=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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.