From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: bit fields && data tearing Date: Fri, 05 Sep 2014 13:34:52 -0700 Message-ID: <540A1E6C.2020005@zytor.com> 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> <540A19B8.4010907@hurleysoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <540A19B8.4010907@hurleysoftware.com> Sender: linux-alpha-owner@vger.kernel.org To: Peter Hurley , Marc Gauthier , "paulmck@linux.vnet.ibm.com" Cc: Michael Cree , 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" List-Id: linux-arch.vger.kernel.org On 09/05/2014 01:14 PM, Peter Hurley wrote: > > 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." > Does this apply in general or only to SMP configurations? I guess non-SMP configurations would still have problems if interrupted in the wrong place... -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from terminus.zytor.com ([198.137.202.10]:51259 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751193AbaIEUfd (ORCPT ); Fri, 5 Sep 2014 16:35:33 -0400 Message-ID: <540A1E6C.2020005@zytor.com> Date: Fri, 05 Sep 2014 13:34:52 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 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> <540A19B8.4010907@hurleysoftware.com> In-Reply-To: <540A19B8.4010907@hurleysoftware.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Peter Hurley , Marc Gauthier , "paulmck@linux.vnet.ibm.com" Cc: Michael Cree , 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" Message-ID: <20140905203452.IkbXUkwwKHPYX1kqiVk9iHy4SQHbPCSMtWTJwXEQB6g@z> On 09/05/2014 01:14 PM, Peter Hurley wrote: > > 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." > Does this apply in general or only to SMP configurations? I guess non-SMP configurations would still have problems if interrupted in the wrong place... -hpa