From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org, pbonzini@redhat.com, cota@braap.org,
stefanha@redhat.com, kwolf@redhat.com
Cc: mttcg@listserver.greensocs.com, fred.konrad@greensocs.com,
a.rigo@virtualopensystems.com, bobby.prani@gmail.com,
nikunj@linux.vnet.ibm.com, mark.burton@greensocs.com,
jan.kiszka@siemens.com, serge.fdrv@gmail.com, rth@twiddle.net,
peter.maydell@linaro.org, claudio.fontana@huawei.com,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: [Qemu-devel] [RFC 0/8] A couple of fixes for ThreadSanitizer
Date: Mon, 19 Sep 2016 16:51:31 +0100 [thread overview]
Message-ID: <20160919155139.28371-1-alex.bennee@linaro.org> (raw)
Hi,
As a precursor to next set of MTTCG reviews in my inbox I had a quick
look at the current state of using ThreadSanitizer with QEMU. There
are a number of patches here:
1,2,3: workarounds for the compiler when tsan enabled
4,5,6,7: various fixes using atomic_set/read()
8: defend the build in Travis
The fixes are mostly theoretical for x86 hosts as individual writes
can't fight with each other to corrupt the final value. However being
explicit about this is the correct thing to do and it reduces the
noise of reports.
With this series I'm still seeing some warnings about qht_insert
racing with tb_alloc but the fixes didn't work so we suspect this
might be a false positive from tsan. I've dropped the workaround from
the series for now.
In system-mode the big generator of warnings is coroutines which are
heavily used in the block layer, for example:
WARNING: ThreadSanitizer: data race (pid=11820)
Read of size 8 at 0x7d0400008fa0 by thread T2:
#0 strlen <null> (libtsan.so.0+0x000000025f6d)
#1 pthread_setname_np <null> (libpthread.so.0+0x000000012395)
#2 <null> <null> (libglib-2.0.so.0+0x000000070bad)
Previous write of size 8 at 0x7d0400008fa0 by main thread (mutexes: write M658):
#0 malloc <null> (libtsan.so.0+0x0000000254a3)
#1 g_malloc <null> (libglib-2.0.so.0+0x00000004f728)
#2 qemu_coroutine_new util/coroutine-gthread.c:144 (qemu-system-aarch64+0x000000c79ad0)
#3 qemu_coroutine_create util/qemu-coroutine.c:75 (qemu-system-aarch64+0x000000c77f9d)
#4 bdrv_prwv_co block/io.c:590 (qemu-system-aarch64+0x000000b9dd75)
I think these are fixable with memory barriers but I'm going to need
to re-watch the KVM Forum video on the subject to remind myself of the
black magic that coroutines involves (unless anyone else wants to
tackle that).
With this series applied you can enable ThreadSanitizer with the
following command line:
./configure --extra-cflags="-g3 -O0 \
-fsantize=thread \
-fsanitize-blacklist=/home/alex/lsrc/qemu/qemu.git/blacklist.tsan" \
--with-coroutine=gthread --disable-pie --enable-debug --enable-debug-info
breakdown:
-fsanitize=thread - enables sanitizer
-fsanitize-blacklist - skip things the compiler finds hard, like SSE
--with-coroutine=gthread - tsan chokes on other forms of coroutine
--disable-pie - tsan no longer works with PIE
--enable-debug --enable-debug-info - better backtraces
Alex Bennée (7):
ui/vnc-enc-tight: add abort() for unexpected default
tcg/optimize: move default return out of if statement
new: blacklist.tsan
qom/object: update class cache atomically
cpu: atomically modify cpu->exit_request
util/qht: atomically set b->hashes
.travis.yml: add gcc sanitizer build
Paolo Bonzini (1):
seqlock: use atomic writes for the sequence
.travis.yml | 16 ++++++++++++++++
blacklist.tsan | 2 ++
cpu-exec.c | 8 ++++----
include/qemu/seqlock.h | 4 ++--
qom/cpu.c | 4 ++--
qom/object.c | 15 ++++++++-------
tcg/optimize.c | 3 +--
ui/vnc-enc-tight.c | 2 ++
util/qht.c | 10 +++++-----
9 files changed, 42 insertions(+), 22 deletions(-)
create mode 100644 blacklist.tsan
--
2.9.3
next reply other threads:[~2016-09-19 15:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 15:51 Alex Bennée [this message]
2016-09-19 15:51 ` [Qemu-devel] [RFC 1/8] ui/vnc-enc-tight: add abort() for unexpected default Alex Bennée
2016-09-20 8:02 ` Marc-André Lureau
2016-09-20 8:24 ` Paolo Bonzini
2016-09-20 14:59 ` Alex Bennée
2016-09-19 15:51 ` [Qemu-devel] [RFC 2/8] tcg/optimize: move default return out of if statement Alex Bennée
2016-09-20 8:02 ` Marc-André Lureau
2016-09-19 15:51 ` [Qemu-devel] [RFC 3/8] new: blacklist.tsan Alex Bennée
2016-09-20 8:03 ` Marc-André Lureau
2016-09-19 15:51 ` [Qemu-devel] [RFC 4/8] seqlock: use atomic writes for the sequence Alex Bennée
2016-09-19 15:51 ` [Qemu-devel] [RFC 5/8] qom/object: update class cache atomically Alex Bennée
2016-09-20 8:36 ` Marc-André Lureau
2016-09-20 14:59 ` Alex Bennée
2016-09-20 15:04 ` Paolo Bonzini
2016-09-19 15:51 ` [Qemu-devel] [RFC 6/8] cpu: atomically modify cpu->exit_request Alex Bennée
2016-09-19 15:51 ` [Qemu-devel] [RFC 7/8] util/qht: atomically set b->hashes Alex Bennée
2016-09-19 18:06 ` Emilio G. Cota
2016-09-19 18:37 ` Paolo Bonzini
2016-09-19 19:06 ` Emilio G. Cota
2016-09-20 7:39 ` Paolo Bonzini
2016-09-22 9:51 ` Alex Bennée
2016-09-19 15:51 ` [Qemu-devel] [RFC 8/8] .travis.yml: add gcc sanitizer build Alex Bennée
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=20160919155139.28371-1-alex.bennee@linaro.org \
--to=alex.bennee@linaro.org \
--cc=a.rigo@virtualopensystems.com \
--cc=bobby.prani@gmail.com \
--cc=claudio.fontana@huawei.com \
--cc=cota@braap.org \
--cc=fred.konrad@greensocs.com \
--cc=jan.kiszka@siemens.com \
--cc=kwolf@redhat.com \
--cc=mark.burton@greensocs.com \
--cc=mttcg@listserver.greensocs.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=serge.fdrv@gmail.com \
--cc=stefanha@redhat.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;
as well as URLs for NNTP newsgroup(s).