From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752124AbaIEUPA (ORCPT ); Fri, 5 Sep 2014 16:15:00 -0400 Received: from mailout32.mail01.mtsvc.net ([216.70.64.70]:37458 "EHLO n23.mail01.mtsvc.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750891AbaIEUO6 (ORCPT ); Fri, 5 Sep 2014 16:14:58 -0400 Message-ID: <540A19B8.4010907@hurleysoftware.com> Date: Fri, 05 Sep 2014 16:14:48 -0400 From: Peter Hurley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Marc Gauthier , "paulmck@linux.vnet.ibm.com" CC: Michael Cree , "H. Peter Anvin" , Benjamin Herrenschmidt , David Laight , Jakub Jelinek , "linux-arch@vger.kernel.org" , Tony Luck , "linux-ia64@vger.kernel.org" , Oleg Nesterov , "linux-kernel@vger.kernel.org" , Paul Mackerras , "linuxppc-dev@lists.ozlabs.org" , Miroslav Franc , Richard Henderson , "linux-alpha@vger.kernel.org" Subject: Re: bit fields && data tearing References: <54079B70.4050200@hurleysoftware.com> <1409785893.30640.118.camel@pasglop> <063D6719AE5E284EB5DD2968C1650D6D17487172@AcuExch.aculab.com> <1409824374.4246.62.camel@pasglop> <5408E458.3@zytor.com> <54090AF4.7060406@hurleysoftware.com> <54091B30.2090509@zytor.com> <20140905081648.GB5281@omega> <20140905180950.GU5001@linux.vnet.ibm.com> <540A05F7.1070202@hurleysoftware.com> <20140905190506.GV5001@linux.vnet.ibm.com> <8CA974F497CA064FA9926E10ABCC061F05F97E7B77@MAILSJ4.global.cadence.com> In-Reply-To: <8CA974F497CA064FA9926E10ABCC061F05F97E7B77@MAILSJ4.global.cadence.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Authenticated-User: 990527 peter@hurleysoftware.com X-MT-ID: 8FA290C2A27252AACF65DBC4A42F3CE3735FB2A4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/05/2014 03:38 PM, Marc Gauthier wrote: > Paul E. McKenney wrote: >> On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote: >>> On 09/05/2014 02:09 PM, Paul E. McKenney wrote: >>>> This commit documents the fact that it is not safe to use bitfields as >>>> shared variables in synchronization algorithms. It also documents that >>>> CPUs must provide one-byte and two-byte load and store instructions >>> ^ >>> atomic >> >> Here you meant non-atomic? My guess is that you are referring to the >> fact that you could emulate a one-byte store on pre-EV56 Alpha CPUs >> using the ll and sc atomic-read-modify-write instructions, correct? >> >>>> in order to be supported by the Linux kernel. (Michael Cree >>>> has agreed to the resulting non-support of pre-EV56 Alpha CPUs: >>>> https://lkml.org/lkml/2014/9/5/143. > [...] > >>>> + and 64-bit systems, respectively. Note that this means that the >>>> + Linux kernel does not support pre-EV56 Alpha CPUs, because these >>>> + older CPUs do not provide one-byte and two-byte loads and stores. >>> ^ >>> non-atomic >> >> I took this, thank you! > > Eum, am I totally lost, or aren't both of these supposed to say "atomic" ? > > Can't imagine requiring a CPU to provide non-atomic loads and stores > (i.e. requiring old Alpha behavior?). Here's how I read the two statements. First, the commit message: "It [this commit] documents that CPUs [supported by the Linux kernel] _must provide_ atomic one-byte and two-byte naturally aligned loads and stores." Second, in the body of the document: "The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these older CPUs _do not provide_ atomic one-byte and two-byte loads and stores." Regards, Peter Hurley