Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp760254imm; Fri, 22 Jun 2018 05:00:55 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJB8/l3I2abpBT6mIxuVf0QDO8rtfVdLeW1fvCvaMTGQ/zRkacTqH0bjjr/EHWLAm7kxXwW X-Received: by 2002:a17:902:b706:: with SMTP id d6-v6mr1398641pls.105.1529668855261; Fri, 22 Jun 2018 05:00:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529668855; cv=none; d=google.com; s=arc-20160816; b=gID8IedFESAGsPZ+9wK82zevu6zIUZHlaKlahsgeKDd7ooAXAxyxgHvnSr2isiSU8n 17amz1WH+InGadyeC/7umgIiHZPbTeuq/T1ztFxKfL0I+QA6wUmxnxu14zuluaycoPZd +oTXKnAdaWi56BK5I1Hs7I6hYfTO4+k+WteqrQgLQUiAXoAid9s2v84u/RFG9B6GiYdK YlqXO8mRynq84UnLd0YtsG4CBtjyrIKVC9qrOqXSwEWlSMBaF/9FNHDnec9JG8Ogvi3t QXp/zXFLj/QnVrGCc43ls/Wv6EqDceSTHrhkVZrsayJkiJsUiZPCHKfCWUBmziUfMJrk NeMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=Q/gMYH8erp+e2LcRlwS9OFsAI050mxgs743CmBMFM+M=; b=WjzHibQJ2ZKfJ519mdpgmvSAdlWGvztiSK/dvzY8xiVbFJVEr01AmZ4LJB0bxJkEau F89IdXelUBu6uWSWRaNSCWxiX2SMXAjbMwi7UyMqMhUX2MouwcUej7pH/usGMnOs79be 2FLSN7pPGHzCPxJ0GKX9wRFAdM/o6dNVCCxUNB84fhVas6M2UGKZyZpiBii6yzi1sUQT 429SRaLIS6/nstdp71LpZcym8e6jzuT+c8TpLfErkmZnWCSYeAJQynSze/6LWYq8yNj3 uwLXe1U+bpwMRtgE4BnY/L5GFMtop7qOWJdaJUJkC0RxKfe2B5pi1i8RinvI3c0tGYnl H/ow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h62-v6si6119251pge.184.2018.06.22.05.00.39; Fri, 22 Jun 2018 05:00:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751345AbeFVL7z (ORCPT + 99 others); Fri, 22 Jun 2018 07:59:55 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:41292 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751005AbeFVL7z (ORCPT ); Fri, 22 Jun 2018 07:59:55 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fWKjB-0004Rz-2s; Fri, 22 Jun 2018 13:59:45 +0200 Date: Fri, 22 Jun 2018 13:59:44 +0200 (CEST) From: Thomas Gleixner To: Fenghua Yu cc: Ingo Molnar , "H. Peter Anvin" , Ashok Raj , Dave Hansen , Rafael Wysocki , Tony Luck , Alan Cox , Ravi V Shankar , Arjan van de Ven , linux-kernel , x86 Subject: Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode In-Reply-To: Message-ID: References: <1527435965-202085-1-git-send-email-fenghua.yu@intel.com> <1527435965-202085-3-git-send-email-fenghua.yu@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Jun 2018, Thomas Gleixner wrote: > The whole thing is simply: > > handle_ac() > { > if (user_mode(regs)) { > do_trap(AC, SIGBUS, ...); > } else { > disable_ac_on_local_cpu(); > WARN_ONCE(1); > } > } > > That wants #AC enabled as early as possible so the kernel gets as much > coverage as it can. If it trips in the kernel it's a bug and needs to be > fixed and we can them fix ONE by ONE. That said, #AC is just yet another badly defined and hastily bolted on (mis)feature. This should have been: Bit A: Enable #AC if CPL < 3 Bit B: Enable #AC if CPL == 3 But that would have been too useful and would allow sensible use of #AC without creating software trainwrecks. Aside of that the spec says: 31 Disable LOCK# assertion for split locked access. Can you pretty please make sure that this bit enforces #AC enable? If 31 is ever set and such an access happens then the resulting havoc will takes ages to decode. That bit is also mentioned in the SDM with ZERO explanation why it exists in the first place and why anyone would ever enable it and without a big fat warning about the possible consequences. Can this pretty please be fixed? Thanks, tglx