All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v2 4/9] memory: Don't do topology update in memory finalize()
Date: Tue, 27 Jul 2021 12:02:05 -0400	[thread overview]
Message-ID: <YQAt/V06OZgjhpI6@t490s> (raw)
In-Reply-To: <1ced8a81-18a2-85fe-0323-03dbc606f73e@redhat.com>

On Tue, Jul 27, 2021 at 03:21:31PM +0200, David Hildenbrand wrote:
> On 23.07.21 21:34, Peter Xu wrote:
> > Topology update could be wrongly triggered in memory region finalize() if
> > there's bug somewhere else.  It'll be a very confusing stack when it
> > happens (e.g., sending KVM ioctl within the RCU thread, and we'll observe it
> > only until it fails!).
> > 
> > Instead of that, we use the push()/pop() helper to avoid memory transaction
> > commit, at the same time we use assertions to make sure there's no pending
> > updates or it's a nested transaction, so it could fail even earlier and in a
> > more explicit way.
> > 
> > Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> >   softmmu/memory.c | 23 +++++++++++++++++++++--
> >   1 file changed, 21 insertions(+), 2 deletions(-)
> > 
> > diff --git a/softmmu/memory.c b/softmmu/memory.c
> > index 1a3e9ff8ad..dfce4a2bda 100644
> > --- a/softmmu/memory.c
> > +++ b/softmmu/memory.c
> > @@ -170,6 +170,12 @@ struct MemoryRegionIoeventfd {
> >       EventNotifier *e;
> >   };
> > +/* Returns whether there's any pending memory updates */
> > +static bool memory_region_has_pending_update(void)
> > +{
> > +    return memory_region_update_pending || ioeventfd_update_pending;
> > +}
> > +
> >   static bool memory_region_ioeventfd_before(MemoryRegionIoeventfd *a,
> >                                              MemoryRegionIoeventfd *b)
> >   {
> > @@ -1756,12 +1762,25 @@ static void memory_region_finalize(Object *obj)
> >        * and cause an infinite loop.
> >        */
> >       mr->enabled = false;
> > -    memory_region_transaction_begin();
> > +
> > +    /*
> > +     * Use push()/pop() instead of begin()/commit() to make sure below block
> > +     * won't trigger any topology update (which should never happen, but it's
> > +     * still a safety belt).
> > +     */
> 
> Hmm, I wonder if we can just keep the begin/end semantics and just do an
> assertion before doing the commit? Does anything speak against that?

That sounds working too for the case of run_on_cpu and similar, but I think
this patch should be able to cover more.  For example, it's possible depth==0
when enter memory_region_finalize(), but some removal of subregions could
further cause memory layout changes.  IMHO we should also bail out early for
those cases too.  Thanks,

-- 
Peter Xu



  reply	other threads:[~2021-07-27 16:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 19:34 [PATCH v2 0/9] memory: Sanity checks memory transaction when releasing BQL Peter Xu
2021-07-23 19:34 ` [PATCH v2 1/9] cpus: Export queue work related fields to cpu.h Peter Xu
2021-07-27 13:02   ` David Hildenbrand
2021-07-23 19:34 ` [PATCH v2 2/9] cpus: Move do_run_on_cpu into softmmu/cpus.c Peter Xu
2021-07-27 13:04   ` David Hildenbrand
2021-07-23 19:34 ` [PATCH v2 3/9] memory: Introduce memory_region_transaction_{push|pop}() Peter Xu
2021-07-27 13:06   ` David Hildenbrand
2021-07-23 19:34 ` [PATCH v2 4/9] memory: Don't do topology update in memory finalize() Peter Xu
2021-07-27 13:21   ` David Hildenbrand
2021-07-27 16:02     ` Peter Xu [this message]
2021-07-28 12:13       ` David Hildenbrand
2021-07-28 13:56         ` Peter Xu
2021-07-28 14:01           ` David Hildenbrand
2021-07-23 19:34 ` [PATCH v2 5/9] cpus: Use qemu_cond_wait_iothread() where proper Peter Xu
2021-07-27 12:49   ` David Hildenbrand
2021-07-23 19:34 ` [PATCH v2 6/9] cpus: Remove the mutex parameter from do_run_on_cpu() Peter Xu
2021-07-27 12:50   ` David Hildenbrand
2021-07-23 19:34 ` [PATCH v2 7/9] cpus: Introduce qemu_mutex_unlock_iothread_prepare() Peter Xu
2021-07-27 12:59   ` David Hildenbrand
2021-07-27 16:08     ` Peter Xu
2021-07-28 12:11       ` David Hildenbrand
2021-07-23 19:34 ` [PATCH v2 8/9] memory: Assert on no ongoing memory transaction before release BQL Peter Xu
2021-07-27 13:00   ` David Hildenbrand
2021-07-23 19:34 ` [PATCH v2 9/9] memory: Delay the transaction pop() until commit completed Peter Xu
2021-07-27 13:02   ` David Hildenbrand
2021-07-23 22:36 ` [PATCH v2 0/9] memory: Sanity checks memory transaction when releasing BQL Peter Xu
2021-07-27 12:41 ` David Hildenbrand
2021-07-27 16:35   ` Peter Xu

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=YQAt/V06OZgjhpI6@t490s \
    --to=peterx@redhat.com \
    --cc=david@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.