All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: "Emilio G. Cota" <cota@braap.org>, qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] tcg: consistently access cpu->tb_jmp_cache atomically
Date: Mon, 26 Jun 2017 14:27:51 -0700	[thread overview]
Message-ID: <0b5a4803-350b-b6e1-62a5-dfc500d03df3@twiddle.net> (raw)
In-Reply-To: <1497486973-25845-1-git-send-email-cota@braap.org>

On 06/14/2017 05:36 PM, Emilio G. Cota wrote:
> Some code paths can lead to atomic accesses racing with memset()
> on cpu->tb_jmp_cache, which can result in torn reads/writes
> and is undefined behaviour in C11.
> 
> These torn accesses are unlikely to show up as bugs, but from code
> inspection they seem possible. For example, tb_phys_invalidate does:
>      /* remove the TB from the hash list */
>      h = tb_jmp_cache_hash_func(tb->pc);
>      CPU_FOREACH(cpu) {
>          if (atomic_read(&cpu->tb_jmp_cache[h]) == tb) {
>              atomic_set(&cpu->tb_jmp_cache[h], NULL);
>          }
>      }
> Here atomic_set might race with a concurrent memset (such as the
> ones scheduled via "unsafe" async work, e.g. tlb_flush_page) and
> therefore we might end up with a torn pointer (or who knows what,
> because we are under undefined behaviour).
> 
> This patch converts parallel accesses to cpu->tb_jmp_cache to use
> atomic primitives, thereby bringing these accesses back to defined
> behaviour. The price to pay is to potentially execute more instructions
> when clearing cpu->tb_jmp_cache, but given how infrequently they happen
> and the small size of the cache, the performance impact I have measured
> is within noise range when booting debian-arm.
> 
> Note that under "safe async" work (e.g. do_tb_flush) we could use memset
> because no other vcpus are running. However I'm keeping these accesses
> atomic as well to keep things simple and to avoid confusing analysis
> tools such as ThreadSanitizer.
> 
> Signed-off-by: Emilio G. Cota<cota@braap.org>
> ---
>   cputlb.c          |  4 ++--
>   include/qom/cpu.h | 11 ++++++++++-
>   qom/cpu.c         |  5 +----
>   translate-all.c   | 25 ++++++++++++-------------
>   4 files changed, 25 insertions(+), 20 deletions(-)

Applied, thanks.


r~

      parent reply	other threads:[~2017-06-26 21:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-15  0:36 [Qemu-devel] [PATCH] tcg: consistently access cpu->tb_jmp_cache atomically Emilio G. Cota
2017-06-15  1:01 ` no-reply
2017-06-15  8:00 ` Paolo Bonzini
2017-06-26 21:27 ` Richard Henderson [this message]

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=0b5a4803-350b-b6e1-62a5-dfc500d03df3@twiddle.net \
    --to=rth@twiddle.net \
    --cc=alex.bennee@linaro.org \
    --cc=cota@braap.org \
    --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.