All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: David Engraf <david.engraf@sysgo.com>, qemu-devel@nongnu.org
Cc: Fam Zheng <famz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] qemu_mutex_iothread_locked not correctly synchronized
Date: Wed, 25 Nov 2015 15:36:49 +0100	[thread overview]
Message-ID: <5655C781.8090201@redhat.com> (raw)
In-Reply-To: <5655BFEA.50407@sysgo.com>



On 25/11/2015 15:04, David Engraf wrote:
>>>
>>
>> No, you don't.  Who is reading iothread_locked during
>> qemu_cond_wait_iothread?  No one, because it is a thread-local variable
>> whose address is never taken.
> 
> prepare_mmio_access is reading iothread_locked by using
> qemu_mutex_iothread_locked after qemu_tcg_wait_io_event calls
> qemu_cond_wait. All one the same thread.

Sure, but who has set iothread_locked to false during the execution of
qemu_cond_wait?  No one, because it's a thread-local variable.  If it's
true before qemu_cond_wait, it will be true after qemu_cond_wait and you
don't need qemu_cond_wait_iothread... unless your compiler is broken and
doesn't generate TLS properly.

Can you compile cpus.c with -S and attach it?

Paolo

> qemu_tcg_cpu_thread_fn
> -> qemu_tcg_wait_io_event
>    -> qemu_cond_wait acquires the mutex
> 
> qemu_tcg_cpu_thread_fn
> -> tcg_exec_all -> tcg_cpu_exec -> cpu_exec
> -> cpu_exec ends up in calling prepare_mmio_access

  reply	other threads:[~2015-11-25 14:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 15:43 [Qemu-devel] [PATCH] qemu_mutex_iothread_locked not correctly synchronized David Engraf
2015-11-24 15:54 ` Paolo Bonzini
2015-11-25  9:08   ` David Engraf
2015-11-25 12:31     ` [Qemu-devel] [PATCH v2] " David Engraf
2015-11-25 13:26       ` Paolo Bonzini
2015-11-25 14:04         ` David Engraf
2015-11-25 14:36           ` Paolo Bonzini [this message]
2015-11-25 15:48             ` David Engraf
2015-11-25 16:16               ` Paolo Bonzini
2015-11-26  9:12                 ` David Engraf
2015-11-26 11:25                   ` Stefan Weil
2015-11-26 14:26                     ` David Engraf

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=5655C781.8090201@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=david.engraf@sysgo.com \
    --cc=famz@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.