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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 35544CA9EA3 for ; Fri, 18 Oct 2019 10:45:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F712222BD for ; Fri, 18 Oct 2019 10:45:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395469AbfJRKpU convert rfc822-to-8bit (ORCPT ); Fri, 18 Oct 2019 06:45:20 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:29243 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725906AbfJRKpT (ORCPT ); Fri, 18 Oct 2019 06:45:19 -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-16-e-9XGDehPgqlQMnchm9hag-1; Fri, 18 Oct 2019 11:45:15 +0100 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 18 Oct 2019 11:45:14 +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; Fri, 18 Oct 2019 11:45:14 +0100 From: David Laight To: "'Luck, Tony'" , Thomas Gleixner , Paolo Bonzini CC: "Li, Xiaoyao" , "Christopherson, Sean J" , "Yu, Fenghua" , "Ingo Molnar" , Borislav Petkov , H Peter Anvin , Peter Zijlstra , Andrew Morton , "Hansen, Dave" , "Radim Krcmar" , "Raj, Ashok" , "Williams, Dan J" , "Prakhya, Sai Praneeth" , "Shankar, Ravi V" , linux-kernel , x86 , "kvm@vger.kernel.org" Subject: RE: [RFD] x86/split_lock: Request to Intel Thread-Topic: [RFD] x86/split_lock: Request to Intel Thread-Index: AQHVhOahH6iHJ8BHzEm2TNVz98K/g6dfc1fAgADCoYA= Date: Fri, 18 Oct 2019 10:45:14 +0000 Message-ID: <3c42bd1c3cb9469f8f762c97f52d8655@AcuMS.aculab.com> References: <1560897679-228028-1-git-send-email-fenghua.yu@intel.com> <1560897679-228028-10-git-send-email-fenghua.yu@intel.com> <20190626203637.GC245468@romley-ivt3.sc.intel.com> <20190925180931.GG31852@linux.intel.com> <3ec328dc-2763-9da5-28d6-e28970262c58@redhat.com> <57f40083-9063-5d41-f06d-fa1ae4c78ec6@redhat.com> <8808c9ac-0906-5eec-a31f-27cbec778f9c@intel.com> <3908561D78D1C84285E8C5FCA982C28F7F4A5F08@ORSMSX115.amr.corp.intel.com> In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F7F4A5F08@ORSMSX115.amr.corp.intel.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: e-9XGDehPgqlQMnchm9hag-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: Luck, Tony > Sent: 18 October 2019 00:28 ... > 2) Fix set_bit() et. al. to not issue atomic operations that cross boundaries. > > Fenghua had been pursuing option #1 in previous iterations. He found a few > more places with the help of the "grep" patterns suggested by David Laight. > So that path is up to ~8 patches now that do one of: > + Change from u32 to u64 > + Force alignment with a union with a u64 > + Change to non-atomic (places that didn't need atomic) > > Downside of strategy #1 is that people will add new misaligned cases in the > future. So this process has no defined end point. > > Strategy #2 begun when I looked at the split-lock issue I saw that with a > constant bit argument set_bit() just does a "ORB" on the affected byte (i.e. > no split lock). Similar for clear_bit() and change_bit(). Changing code to also > do that for the variable bit case is easy. > > test_and_clr_bit() needs more care, but luckily, we had Peter Anvin nearby > to give us a neat solution. Changing the x86-64 bitops to use 32bit memory cycles is trivial (provided you are willing to accept a limit of 2G bits). OTOH this only works because x86 is LE. On any BE systems passing an 'int []' to any of the bit-functions is so terribly wrong it is unbelievable. So changing the x86-64 bitops is largely papering over a crack. In essence any code that casts the argument to any of the bitops functions is almost certainly badly broken on BE systems. The x86 cpu features code is always LE. It probably ought to have a typedef for a union of long [] and int []. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)