From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Subject: Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}() Date: Tue, 21 Jun 2016 14:27:22 +1000 (AEST) Message-ID: References: <20160531101925.702692792@infradead.org> <20160531102642.333689893@infradead.org> <20160616101309.GD30921@twins.programming.kicks-ass.net> <20160617154024.GY30154@twins.programming.kicks-ass.net> <87twgniwh7.fsf@linux-m68k.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <87twgniwh7.fsf@linux-m68k.org> Sender: linux-m68k-owner@vger.kernel.org To: Andreas Schwab Cc: Peter Zijlstra , Geert Uytterhoeven , Linus Torvalds , Ingo Molnar , Thomas Gleixner , Will Deacon , Paul McKenney , boqun.feng@gmail.com, waiman.long@hpe.com, =?ISO-8859-15?Q?Fr=E9d=E9ric_Weisbecker?= , "linux-kernel\\@vger.kernel.org" , Linux-Arch , Richard Henderson , Vineet Gupta , Russell King , Hans-Christian Noren Egtvedt , Miao Steven , Yoshinori Sato , Richard Kuo , Tony Luck , James Hogan , Ralf Baechle List-Id: linux-arch.vger.kernel.org On Mon, 20 Jun 2016, Andreas Schwab wrote: > Peter Zijlstra writes: > > > Could either of you comment on the below patch? > > > > All atomic functions that return a value should imply full memory > > barrier semantics -- this very much includes a compiler barrier / > > memory clobber. > > I wonder if it is possible to find a case where this makes a real > difference, ie. where the compiler erroneously reused a value due to the > missing barrier. What the compiler does erroneously is a compiler bug by definition. But I think that was not what you meant. Perhaps you're asking whether gcc in particular does what you expect, despite ambiguous source code. But what about other tools like static analyzers? Ambiguous code is likely to attract patches like this for as long as it remains ambiguous. That's a waste of everyone's time, if patches like this could be written and reviewed just once. -- > > Andreas. > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from kvm5.telegraphics.com.au ([98.124.60.144]:53724 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751545AbcFUEpX (ORCPT ); Tue, 21 Jun 2016 00:45:23 -0400 Date: Tue, 21 Jun 2016 14:27:22 +1000 (AEST) From: Finn Thain Subject: Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}() In-Reply-To: <87twgniwh7.fsf@linux-m68k.org> Message-ID: References: <20160531101925.702692792@infradead.org> <20160531102642.333689893@infradead.org> <20160616101309.GD30921@twins.programming.kicks-ass.net> <20160617154024.GY30154@twins.programming.kicks-ass.net> <87twgniwh7.fsf@linux-m68k.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andreas Schwab Cc: Peter Zijlstra , Geert Uytterhoeven , Linus Torvalds , Ingo Molnar , Thomas Gleixner , Will Deacon , Paul McKenney , boqun.feng@gmail.com, waiman.long@hpe.com, =?ISO-8859-15?Q?Fr=E9d=E9ric_Weisbecker?= , "linux-kernel\\@vger.kernel.org" , Linux-Arch , Richard Henderson , Vineet Gupta , Russell King , Hans-Christian Noren Egtvedt , Miao Steven , Yoshinori Sato , Richard Kuo , Tony Luck , James Hogan , Ralf Baechle , David Howells , "James E.J. Bottomley" , Michael Ellerman , Martin Schwidefsky , Rich Felker , "David S. Miller" , cmetcalf@mellanox.com, Max Filippov , Arnd Bergmann , dbueso@suse.de, Wu Fengguang , linux-m68k Message-ID: <20160621042722.juhB4Z4xkMGmWPTnnSTFa4OPioEOl7E3T74Clys936Y@z> On Mon, 20 Jun 2016, Andreas Schwab wrote: > Peter Zijlstra writes: > > > Could either of you comment on the below patch? > > > > All atomic functions that return a value should imply full memory > > barrier semantics -- this very much includes a compiler barrier / > > memory clobber. > > I wonder if it is possible to find a case where this makes a real > difference, ie. where the compiler erroneously reused a value due to the > missing barrier. What the compiler does erroneously is a compiler bug by definition. But I think that was not what you meant. Perhaps you're asking whether gcc in particular does what you expect, despite ambiguous source code. But what about other tools like static analyzers? Ambiguous code is likely to attract patches like this for as long as it remains ambiguous. That's a waste of everyone's time, if patches like this could be written and reviewed just once. -- > > Andreas. > >