From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755660AbaIEASC (ORCPT ); Thu, 4 Sep 2014 20:18:02 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:37223 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755577AbaIEAR6 (ORCPT ); Thu, 4 Sep 2014 20:17:58 -0400 Date: Thu, 4 Sep 2014 17:17:51 -0700 From: "Paul E. McKenney" To: "H. Peter Anvin" Cc: Peter Hurley , One Thousand Gnomes , Jakub Jelinek , Mikael Pettersson , Benjamin Herrenschmidt , Richard Henderson , Oleg Nesterov , Miroslav Franc , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Tony Luck , linux-ia64@vger.kernel.org Subject: Re: bit fields && data tearing Message-ID: <20140905001751.GL5001@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20140712181328.GA8738@redhat.com> <54079B70.4050200@hurleysoftware.com> <1409785893.30640.118.camel@pasglop> <21512.10628.412205.873477@gargle.gargle.HOWL> <20140904090952.GW17454@tucnak.redhat.com> <540859EC.5000407@hurleysoftware.com> <20140904175044.4697aee4@alan.etchedpixels.co.uk> <5408C0AB.6050801@hurleysoftware.com> <5408E4A3.2060303@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5408E4A3.2060303@zytor.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14090500-3532-0000-0000-000004620A05 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote: > On 09/04/2014 12:42 PM, Peter Hurley wrote: > > > > Or we could give up on the Alpha. > > > > If Alpha is turning into Voyager (kept alive only as a museum piece, but > actively causing problems) then please let's kill it. Sorry for being slow to join this thread, but I propose the following patch. If we can remove support for all CPUs that to not support direct access to bytes and shorts (which I would very much like to see happen), I will remove the last non-guarantee. Thanx, Paul ------------------------------------------------------------------------ documentation: Record limitations of bitfields and small variables This commit documents the fact that it is not safe to use bitfields as shared variables in synchronization algorithms. Signed-off-by: Paul E. McKenney diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 87be0a8a78de..a28bfe4fd759 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -269,6 +269,26 @@ And there are a number of things that _must_ or _must_not_ be assumed: STORE *(A + 4) = Y; STORE *A = X; STORE {*A, *(A + 4) } = {X, Y}; +And there are anti-guarantees: + + (*) These guarantees do not apply to bitfields, because compilers often + generate code to modify these using non-atomic read-modify-write + sequences. Do not attempt to use bitfields to synchronize parallel + algorithms. + + (*) Even in cases where bitfields are protected by locks, all fields + in a given bitfield must be protected by one lock. If two fields + in a given bitfield are protected by different locks, the compiler's + non-atomic read-modify-write sequences can cause an update to one + field to corrupt the value of an adjacent field. + + (*) These guarantees apply only to properly aligned and sized scalar + variables. "Properly sized" currently means "int" and "long", + because some CPU families do not support loads and stores of + other sizes. ("Some CPU families" is currently believed to + be only Alpha 21064. If this is actually the case, a different + non-guarantee is likely to be formulated.) + ========================= WHAT ARE MEMORY BARRIERS?