From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14788 invoked by alias); 3 Mar 2009 20:02:43 -0000 Received: (qmail 11772 invoked by uid 48); 3 Mar 2009 20:02:30 -0000 Date: Tue, 03 Mar 2009 21:44:00 -0000 Message-ID: <20090303200230.11771.qmail@sourceware.org> From: "jistone at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20081001203800.6932.mhiramat@redhat.com> References: <20081001203800.6932.mhiramat@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/6932] c->busy can be non-atomic. X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q1/txt/msg00578.txt.bz2 ------- 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.