This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/6932] c->busy can be non-atomic.
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 3 Mar 2009 20:02:30 -0000
- Subject: [Bug translator/6932] c->busy can be non-atomic.
- References: <20081001203800.6932.mhiramat@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From jistone at redhat dot com 2009-03-03 20:02 -------
My apologies if I'm over-thinking this, but I really do think we have a subtle
bug here...
(In reply to comment #16)
> For the "busy" flag, I don't think ordering issues arise if we continue to
> use the atomic.h API. Concurrent reads/writes are SMP-synchronized - that's
> the whole point.
Yes, but only regarding that particular variable. It says nothing about the
ordering wrt neighboring reads/writes.
> Note that we only write c->fields if the atomic_inc_return
> returned the proper value.
Ah, ok, atomic_ops.txt does document that atomic operations which return a value
will act as a full memory barrier both before and after. The atomic_dec()s may
still be an issue though, which we could fix either by making them
atomic_dec_return(), or inserting an smp_mb__before_atomic_dec().
(In reply to comment #17)
> Sure, I agreed. I hope someone who has bigger SMP machine tests this patch
> and find meaningful results.
Unfortunately, I don't have any such machines. But anyway, you could also
consider using local_t, which keeps the same barrier semantics as atomic_t
without the cross-CPU bus locks.
> BTW, I think we can check busy flags safely with smp_call_function.
It may be safe, but why would you want to do this? I see no advantage over the
simple loop that we have now...
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6932
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.