From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932251AbbI1I7s (ORCPT ); Mon, 28 Sep 2015 04:59:48 -0400 Received: from smtp-out4.electric.net ([192.162.216.188]:53592 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756284AbbI1I7p (ORCPT ); Mon, 28 Sep 2015 04:59:45 -0400 From: David Laight To: "'Rafael J. Wysocki'" , James Bottomley CC: Viresh Kumar , Johannes Berg , Greg Kroah-Hartman , Linaro Kernel Mailman List , "QCA ath9k Development" , Intel Linux Wireless , "linux-doc@vger.kernel.org" , Linux Kernel Mailing List , "linux-arm-kernel@lists.infradead.org" , Linux ACPI , "open list:BLUETOOTH DRIVERS" , "open list:AMD IOMMU (AMD-VI)" , "netdev@vger.kernel.org" , "open list:NETWORKING DRIVERS (WIRELESS)" , "open list:TARGET SUBSYSTEM" , "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" , "open list:EDAC-CORE" , Linux Memory Management List , "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." Subject: RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Thread-Topic: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Thread-Index: AQHQ97mJ4eNtDEesrUmHo3Etiv4ZeJ5Nljjt///wWQCAABobAIAAAfcA///94YCAAAkwAIABf7wAgAEylICAAUqIoA== Date: Mon, 28 Sep 2015 08:58:17 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CBA3BF7@AcuExch.aculab.com> References: <2524822.pQu4UKMrlb@vostro.rjw.lan> <1443297128.2181.11.camel@HansenPartnership.com> <3461169.v5xKdGLGjP@vostro.rjw.lan> In-Reply-To: <3461169.v5xKdGLGjP@vostro.rjw.lan> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t8S8xpUL009507 From: Rafael J. Wysocki > Sent: 27 September 2015 15:09 ... > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long. > > > Initially, all of them are equal to 0. > > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time. > > > > > > What's the result? > > > > I think every CPU's cache architecure guarantees adjacent store > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're > > thinking of old alpha SMP system where the lowest store width is 32 bits > > and thus you have to do RMW to update a byte, this was usually fixed by > > padding (assuming the structure is not packed). However, it was such a > > problem that even the later alpha chips had byte extensions. Does linux still support those old Alphas? The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations. > OK, thanks! You still have to ensure the compiler doesn't do wider rmw cycles. I believe the recent versions of gcc won't do wider accesses for volatile data. David {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I