From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A411C04AB5 for ; Thu, 6 Jun 2019 16:34:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DD65C20652 for ; Thu, 6 Jun 2019 16:34:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727427AbfFFQe5 convert rfc822-to-8bit (ORCPT ); Thu, 6 Jun 2019 12:34:57 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([146.101.78.151]:40843 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727157AbfFFQe5 (ORCPT ); Thu, 6 Jun 2019 12:34:57 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-111-wSjFIz9gN-O0BTNia_e76w-1; Thu, 06 Jun 2019 17:34:53 +0100 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b::d117) by AcuMS.aculab.com (fd9f:af1c:a25b::d117) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 6 Jun 2019 17:34:52 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Thu, 6 Jun 2019 17:34:52 +0100 From: David Laight To: "'paulmck@linux.ibm.com'" , Geert Uytterhoeven CC: Vineet Gupta , Peter Zijlstra , Will Deacon , arcml , lkml , "linux-arch@vger.kernel.org" Subject: RE: single copy atomicity for double load/stores on 32-bit systems Thread-Topic: single copy atomicity for double load/stores on 32-bit systems Thread-Index: AQHVHExZF0f//oAV60q3cSBNG5qc66aO0bMg Date: Thu, 6 Jun 2019 16:34:52 +0000 Message-ID: <8d1666df180d4d01aaebb5d41370b338@AcuMS.aculab.com> References: <2fd3a455-6267-5d21-c530-41964a4f6ce9@synopsys.com> <20190531082112.GH2623@hirez.programming.kicks-ass.net> <20190603201324.GN28207@linux.ibm.com> <20190606094340.GD28207@linux.ibm.com> In-Reply-To: <20190606094340.GD28207@linux.ibm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: wSjFIz9gN-O0BTNia_e76w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Paul E. McKenney > Sent: 06 June 2019 10:44 ... > But m68k is !SMP-only, correct? If so, the only issues would be > interactions with interrupt handlers and the like, and doesn't current > m68k hardware use exact interrupts? Or is it still possible to interrupt > an m68k in the middle of an instruction like it was in the bad old days? Hardware interrupts were always on instruction boundaries, the mid-instruction interrupts would only happen for page faults (etc). There were SMP m68k systems (but I can't remember one). It was important to continue from a mid-instruction trap on the same cpu - unless you could guarantee that all the cpus had exactly the same version of the microcode. In any case you could probably use the 'cmp2' instruction for an atomic 64bit write. OTOH setting that up was such a PITA it was always easier to disable interrupts. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)