Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp4010576ybt; Sun, 5 Jul 2020 13:56:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytn+17mQXsQzhYcBi4Ho1pUX2Hh43ErucJX0xgh0XSlxvj4jdtMATiFokJVdigYQTWwp6t X-Received: by 2002:a17:906:edb3:: with SMTP id sa19mr40035042ejb.21.1593982599031; Sun, 05 Jul 2020 13:56:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593982599; cv=none; d=google.com; s=arc-20160816; b=UZF1YrNgJbQlZsRt+4F0q2ZAEB/KB+wAzZ4tR7g/QGYqorNsIqsRe+JCzq5361ETN1 8xdi4btdt7ESQy5L2hSJgwow9HJDIWiHAGUJe61o3oH0FbroXR4ZFE2/q73Yyq/F5f1J PN0/OKXYxJaK2eAFELzmWmvPcQr+gUtK0IqSO2WTDeNrIJTLca43FlqB47RMZOFGMpMv 8LlkKCs+YAW5tFG4LPM3+RTWGwbvKN/0ADZCbWvNYdtUGcmObm3emEWQ26TIuwhNRj2S xCYJDEGgn0/+8l5dxchOb/pDfHnV4W6a4PzEE67c+LHt1zQOC2XVriBXE3OJFHqtTO4a 9K5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9DfGtmGOeoytPECkO3Kp+vmNcFK2hf7SRurNtGwRufs=; b=IK6aj4OhbT7J8dm0vagIfVT0N7JtYRZ9CJ2HEMeazsOqDmdAlBN2KsksYP6UUwYXxv FoAORGSIgtaC94lB5ph38blIrFt0dFPjhCjnhWx+ovhPTfbGmCTyFe0RnH1onccyub5Y Ih6/UT/pCKjU5/D17V9iPLiMeZVp6wmpP3CyjOCfBkQp5HQeB3YGouoxyGxl/ftlsmJj 95Aa0zVijJo/mdvPSeGIm45rDD1BZIyfXVdFRYs9NKYCylCPhmEJ3Ak4hQHgFrXUh9kV D/QQxciqaayXGR2eYX00f7DusvOC8KMP2hNMOpH+WGpIS26uQDURFRmIvSKjdCVHPIZ/ 8jig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=mXjOt4fK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n16si11703779edt.25.2020.07.05.13.56.16; Sun, 05 Jul 2020 13:56:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=mXjOt4fK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728356AbgGEUz4 (ORCPT + 99 others); Sun, 5 Jul 2020 16:55:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:58648 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728038AbgGEUzz (ORCPT ); Sun, 5 Jul 2020 16:55:55 -0400 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D984821919 for ; Sun, 5 Jul 2020 20:55:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593982555; bh=Er1cSupQus9TnIpV2t16NGTYwoMgLeV2WAfF/89/hpw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mXjOt4fK68MU3jlvN3QsElD7RRwGxT7ogtTD+y3gmOyHQFztDUn3l7EVlSAM3c52j Npt+YkGIyndAVBE1xBjf4BQUOOXjXgZ+hV3Zob2ML66OTRH7nfFplsWphGjLOGOOpN 4uF5bmejh4qSEf+0lmfzpEf0IBMG7wyAWo0ST/58= Received: by mail-wm1-f54.google.com with SMTP id o8so37082718wmh.4 for ; Sun, 05 Jul 2020 13:55:54 -0700 (PDT) X-Gm-Message-State: AOAM531ouUavOcT1xaysp0iitWfOOkl/oXFFCUW72/7DQYZOjOs4b80y l9PQli7mnPLObsUVsmiUuTfkmifh+uHcu5ChNp8Llg== X-Received: by 2002:a1c:1b90:: with SMTP id b138mr45880509wmb.21.1593982553413; Sun, 05 Jul 2020 13:55:53 -0700 (PDT) MIME-Version: 1.0 References: <20200629214956.GA12962@linux.intel.com> <20200704203809.76391-1-dpreed@deepplum.com> <20200704203809.76391-3-dpreed@deepplum.com> <1593978728.059424180@apps.rackspace.com> In-Reply-To: <1593978728.059424180@apps.rackspace.com> From: Andy Lutomirski Date: Sun, 5 Jul 2020 13:55:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/3] Fix undefined operation fault that can hang a cpu on crash or panic To: "David P. Reed" Cc: Andy Lutomirski , Sean Christopherson , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , "H. Peter Anvin" , Allison Randal , Enrico Weigelt , Greg Kroah-Hartman , Kate Stewart , "Peter Zijlstra (Intel)" , Randy Dunlap , Martin Molnar , Alexandre Chartre , Jann Horn , Dave Hansen , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 5, 2020 at 12:52 PM David P. Reed wrote: > > Thanks, will handle these. 2 questions below. > > On Sunday, July 5, 2020 2:22pm, "Andy Lutomirski" said: > > > On Sat, Jul 4, 2020 at 1:38 PM David P. Reed wrote: > >> > >> Fix: Mask undefined operation fault during emergency VMXOFF that must be > >> attempted to force cpu exit from VMX root operation. > >> Explanation: When a cpu may be in VMX root operation (only possible when > >> CR4.VMXE is set), crash or panic reboot tries to exit VMX root operation > >> using VMXOFF. This is necessary, because any INIT will be masked while cpu > >> is in VMX root operation, but that state cannot be reliably > >> discerned by the state of the cpu. > >> VMXOFF faults if the cpu is not actually in VMX root operation, signalling > >> undefined operation. > >> Discovered while debugging an out-of-tree x-visor with a race. Can happen > >> due to certain kinds of bugs in KVM. > > > > Can you re-wrap lines to 68 characters? Also, the Fix: and > > I used 'scripts/checkpatch.pl' and it had me wrap to 75 chars: > "WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line)" > > Should I submit a fix to checkpatch.pl to say 68? 75 is probably fine too, but something is odd about your wrapping. You have long lines mostly alternating with short lines. It's as if you wrote 120-ish character lines and then wrapped to 75 without reflowing. > > > Explanation: is probably unnecessary. You could say: > > > > Ignore a potential #UD failut during emergency VMXOFF ... > > > > When a cpu may be in VMX ... > > > >> > >> Fixes: 208067 > >> Reported-by: David P. Reed > > > > It's not really necessary to say that you, the author, reported the > > problem, but I guess it's harmless. > > > >> Suggested-by: Thomas Gleixner > >> Suggested-by: Sean Christopherson > >> Suggested-by: Andy Lutomirski > >> Signed-off-by: David P. Reed > >> --- > >> arch/x86/include/asm/virtext.h | 20 ++++++++++++++------ > >> 1 file changed, 14 insertions(+), 6 deletions(-) > >> > >> diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h > >> index 0ede8d04535a..0e0900eacb9c 100644 > >> --- a/arch/x86/include/asm/virtext.h > >> +++ b/arch/x86/include/asm/virtext.h > >> @@ -30,11 +30,11 @@ static inline int cpu_has_vmx(void) > >> } > >> > >> > >> -/* Disable VMX on the current CPU > >> +/* Exit VMX root mode and isable VMX on the current CPU. > > > > s/isable/disable/ > > > > > >> /* Disable VMX if it is supported and enabled on the current CPU > >> -- > >> 2.26.2 > >> > > > > Other than that: > > > > Reviewed-by: Andy Lutomirski > > As a newbie, I have a process question - should I resend the patch with the 'Reviewed-by' line, as well as correcting the other wording? Thanks! Probably. Sometimes a maintainer will apply the patch and make these types of cosmetic changes, but it's easier if you resubmit. That being said, for non-urgent patches, it's usually considered polite to wait a day or two to give other people a chance to comment. --Andy