All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, mttcg@greensocs.com,
	fred.konrad@greensocs.com, a.rigo@virtualopensystems.com,
	cota@braap.org, 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,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v3 03/15] exec-all.h: revert tb_page_addr_t to target_ulong
Date: Tue, 04 Oct 2016 15:08:28 +0100	[thread overview]
Message-ID: <87oa30ryub.fsf@linaro.org> (raw)
In-Reply-To: <9cc2a403-2116-2c8b-9573-62f1fd316fcf@redhat.com>


Paolo Bonzini <pbonzini@redhat.com> writes:

> On 03/10/2016 11:32, Alex Bennée wrote:
>> 1. For atomic_read/set fall back to plain access for sizeof(*ptr) >
>> sizeof(void *)
>>
>> This would throw up warnings in ThreadSanitizer on 64-on-32 but
>> practically generate the same code as before.
>>
>> 2. Split sizeof(*ptr) > sizeof(void *) accesses over two
>>
>> This would keep the sanitizer happy but be incorrect behaviour, you
>> could get tears.
>>
>> 3. Add a generic 64-on-32 lock for these accesses
>>
>> It would be a global lock for any oversized access which could end up
>> being highly contended but at least any behaviour would be always
>> correct.
>
> (3) is what libatomic does.
>
> For generic statistics/counters I have written, but not yet upstreamed,
> a module which defines two abstract data types:
>
> - Stat64 is a 64-bit value and it can do 64-bit add/min/max.  Reads
> block writes, but writes try to bypass the lock if possible (e.g.
> min/max that don't modify the stored value, or add that only touches the
> lower 32-bits).
>
> - Count64 is actually a 63-bit value and can do 32-bit add or 63-bit
> get/set.  Writes block reads, but 32-bit adds try pretty hard not to.
>
> These are meant for the block layer, so they would be necessary even if
> 64-on-32 went away.  Unfortunately, neither is a perfect replacement for
> a 64-bit variable...

With rth's CONFIG_ATOMIC64 patch mingw doesn't complain with this:

atomic.h: relax sizeof(*ptr) > sizeof(*void) check

If the compiler can already handle oversized accesses let it do so.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

1 file changed, 10 insertions(+), 4 deletions(-)
include/qemu/atomic.h | 14 ++++++++++----

modified   include/qemu/atomic.h
@@ -99,15 +99,21 @@
  * no effect on the generated code but not using the atomic primitives
  * will get flagged by sanitizers as a violation.
  */
+#ifdef CONFIG_ATOMIC64
+#define ATOMIC_BUILD_BUG_ON(ptr) QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(uint64_t));
+#else
+#define ATOMIC_BUILD_BUG_ON(ptr) QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *));
+#endif
+
 #define atomic_read(ptr)                              \
     ({                                                \
-    QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *)); \
-    __atomic_load_n(ptr, __ATOMIC_RELAXED);           \
+        ATOMIC_BUILD_BUG_ON(ptr);                     \
+        __atomic_load_n(ptr, __ATOMIC_RELAXED);       \
     })

 #define atomic_set(ptr, i)  do {                      \
-    QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *)); \
-    __atomic_store_n(ptr, i, __ATOMIC_RELAXED);       \
+        ATOMIC_BUILD_BUG_ON(ptr);                     \
+        __atomic_store_n(ptr, i, __ATOMIC_RELAXED);   \
 } while(0)

 /* See above: most compilers currently treat consume and acquire the

  reply	other threads:[~2016-10-04 14:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-30 21:30 [Qemu-devel] [PATCH v3 00/15] A number of fixes for ThreadSanitizer Alex Bennée
2016-09-30 21:30 ` [Qemu-devel] [PATCH v3 01/15] atomic.h: fix __SANITIZE_THREAD__ build Alex Bennée
2016-09-30 21:30 ` [Qemu-devel] [PATCH v3 02/15] atomic.h: comment on use of atomic_read/set Alex Bennée
2016-09-30 21:30 ` [Qemu-devel] [PATCH v3 03/15] exec-all.h: revert tb_page_addr_t to target_ulong Alex Bennée
2016-10-03  8:59   ` Paolo Bonzini
2016-10-03  9:32     ` Alex Bennée
2016-10-03 10:10       ` Paolo Bonzini
2016-10-04 14:08         ` Alex Bennée [this message]
2016-10-03 15:31       ` Emilio G. Cota
2016-10-03 16:16         ` Alex Bennée
2016-09-30 21:30 ` [Qemu-devel] [PATCH v3 04/15] tcg/optimize: move default return out of if statement Alex Bennée
2016-09-30 21:30 ` [Qemu-devel] [PATCH v3 05/15] seqlock: use atomic writes for the sequence Alex Bennée
2016-09-30 22:14   ` Jonathan Neuschäfer
2016-09-30 22:45     ` Alex Bennée
2016-09-30 22:58       ` Jonathan Neuschäfer
2016-09-30 21:30 ` [Qemu-devel] [PATCH v3 06/15] qom/object: update class cache atomically Alex Bennée
2016-09-30 21:30 ` [Qemu-devel] [PATCH v3 07/15] qom/cpu: atomically clear the tb_jmp_cache Alex Bennée
2016-09-30 21:30 ` [Qemu-devel] [PATCH v3 08/15] cpu: atomically modify cpu->exit_request Alex Bennée
2016-09-30 21:31 ` [Qemu-devel] [PATCH v3 09/15] util/qht: atomically set b->hashes Alex Bennée
2016-09-30 21:31 ` [Qemu-devel] [PATCH v3 10/15] linux-user/syscall: extend lock around cpu-list Alex Bennée
2016-09-30 21:31 ` [Qemu-devel] [PATCH v3 11/15] qga/command: use QEMU atomic primitives Alex Bennée
2016-09-30 21:31 ` [Qemu-devel] [PATCH v3 12/15] .travis.yml: add gcc sanitizer build Alex Bennée
2016-09-30 21:31 ` [Qemu-devel] [PATCH v3 13/15] tcg: ensure cpu_tb_exec/tb_gen_code use atomic_read/write Alex Bennée
2016-09-30 22:12   ` [Qemu-devel] [PATCH] fixup! " Alex Bennée
2016-10-03  8:43   ` [Qemu-devel] [PATCH v3 13/15] " Paolo Bonzini
2016-10-03  9:48     ` Alex Bennée
2016-10-03  9:53       ` Paolo Bonzini
2016-09-30 21:31 ` [Qemu-devel] [PATCH v3 14/15] tcg: update remaining TranslationBuffer fields atomically Alex Bennée
2016-09-30 21:31 ` [Qemu-devel] [PATCH v3 15/15] translate-all: mark updates to PageDesc as atomic Alex Bennée
2016-10-03  8:50   ` Paolo Bonzini
2016-09-30 21:54 ` [Qemu-devel] [PATCH v3 00/15] A number of fixes for ThreadSanitizer no-reply
2016-09-30 22:06 ` no-reply
2016-10-03  9:25 ` Paolo Bonzini
2016-10-03  9:43   ` 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=87oa30ryub.fsf@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=crosthwaite.peter@gmail.com \
    --cc=fred.konrad@greensocs.com \
    --cc=jan.kiszka@siemens.com \
    --cc=mark.burton@greensocs.com \
    --cc=mttcg@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 \
    /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.