Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1430762yba; Thu, 4 Apr 2019 10:33:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqyFbxPtaV/++oUwcToxLuAzUIBcLr6cBENzhRNPJV+9meY7oSmf1RRATjijZjT2imfCJSUA X-Received: by 2002:a17:902:846:: with SMTP id 64mr7751219plk.266.1554399210298; Thu, 04 Apr 2019 10:33:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554399210; cv=none; d=google.com; s=arc-20160816; b=UPTuegQQvb8Q0Z263/dMZGtWmKmR3xgSDp817HTo7Y6OxuXtoKz93FnDitIyp4gKM3 Fu7+zPHCgyAqxcTezKnOfFMe65arHJ/C9WOnqjEX0doN3f1ti0zVAbJldkggmfwHzr5Z MsXFCFCMMd/mass/XZPNm8mCvGUcHPDJT7eixec/PTz1531Q2M79lBIRJD6foasn9gBH yrUCFvY/QtUWbCyYlH1w0A/d8ZQg/HkQHAhIIN4Bk5MV1KV0X4nBxxEpKuUZPy2mQwoo MQmxI/CUFN2B94aM3vQLKm3bgruoCo2NAN/KuE5n8T8dUNc9yo5FrohQo0p5bcPXpluz VFuQ== 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; bh=SDgqJLA1KyQ8s3VvmdRKMLywl8VmErme3F0PWWzKL5Y=; b=qpx9pf1WWqsQBeFSjOwzjrn6ysaap4OKApbwbcln/BkGBXcOz3xNZGCYatxg0+YYvf Rvuht5g85NH9yqjqflB1s0iLUZZdjhCx1xqBmUAeBSFtUR2HAXGzag+Uj8XkfLZv4AE3 RvHfsJ2HEy1UM4ESD3TO0GQXTrEv4vbSLe54+JFdm36INwxl55kCFh8dJjZYLczx47gg ctuG4PiqkqaT1o2XFJ9aI/SSZV9GRMvNqDeSVbAj7nONZnMaJGqgt7uRDdh0aQtfgUOD N7m7yRN2yXX2k4yruLHfQqaEfkfxuYKqa8fVz1vT7tdXWILhBfoIkrbGVjulrRN4I/rm 2VWQ== 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 64si17194786plk.279.2019.04.04.10.33.14; Thu, 04 Apr 2019 10:33:30 -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 S1729384AbfDDRcR (ORCPT + 99 others); Thu, 4 Apr 2019 13:32:17 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:46114 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727562AbfDDRcR (ORCPT ); Thu, 4 Apr 2019 13:32:17 -0400 Received: from p5492e2fc.dip0.t-ipconnect.de ([84.146.226.252] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hC6DY-00074s-FU; Thu, 04 Apr 2019 19:32:00 +0200 Date: Thu, 4 Apr 2019 19:31:59 +0200 (CEST) From: Thomas Gleixner To: Fenghua Yu cc: Ingo Molnar , Borislav Petkov , H Peter Anvin , Dave Hansen , Paolo Bonzini , Ashok Raj , Peter Zijlstra , Kalle Valo , Xiaoyao Li , Michael Chan , Ravi V Shankar , linux-kernel , x86 , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v6 10/20] x86/split_lock: Handle #AC exception for split lock In-Reply-To: <1554326526-172295-11-git-send-email-fenghua.yu@intel.com> Message-ID: References: <1554326526-172295-1-git-send-email-fenghua.yu@intel.com> <1554326526-172295-11-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 X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Apr 2019, Fenghua Yu wrote: > +dotraplinkage void do_alignment_check(struct pt_regs *regs, long error_code) > +{ > + unsigned int trapnr = X86_TRAP_AC; > + char str[] = "alignment check"; > + int signr = SIGBUS; > + > + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); > + > + /* > + * WARN*()s end up here; fix them up before we call the > + * notifier chain. > + */ How exactly is WARN*() ending up here? > + if (!user_mode(regs) && fixup_bug(regs, trapnr)) And that fixup_bug() check does what? int fixup_bug(struct pt_regs *regs, int trapnr) { if (trapnr != X86_TRAP_UD) return 0; Copy and paste from do_error_trap() .... > + return; > + > + if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) == > + NOTIFY_STOP) > + return; > + > + cond_local_irq_enable(regs); > + if (!user_mode(regs) && > + static_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT)) { > + /* > + * Only split lock can generate #AC from kernel at this point. > + * Warn and disable split lock detection on this CPU. The > + * faulting instruction will be executed without generating > + * another #AC fault. User needs to check the warning and > + * fix the split lock issue in the faulting instruction. "User needs to check the warning and fix the issue ..." I'm looking forward to all the fixes from Joe Users. Please remove that sentence. It's useless. Users report warnings if at all and the kernel developers who actually look at them surely don't need an advice like that. Thanks, tglx