Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp3479216ybh; Mon, 5 Aug 2019 19:42:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqzlJvhF5u21kz++hZ0f7IkteIA1MCmYe8M0DWHsnB27rYIRQEygXO37779nlckwPhp0rm82 X-Received: by 2002:aa7:8ad0:: with SMTP id b16mr1187735pfd.45.1565059375778; Mon, 05 Aug 2019 19:42:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565059375; cv=none; d=google.com; s=arc-20160816; b=L7Hkc1aeKGdr8dKSNVxSAlTK+xiSWdwBs577Qg014d+lnwITMYqBa50/RGs+22jL6w NJRbZSL/BOmTpwECa02IELITnL6vLXnR9lJ/f2Ea9Acy4XBXS90JpYTDUKOKC01pUSTr O96h6SvGtHrjo2rwTWCtfI9bQW2V8lTp+CnQ9TzSgg6+qvahYISAcplM31rOyhtHTlzi dyIz4CmFyqqr9nEIK5t4ZuXAAHPfjFtPUd5Tzl4sPmToOaf1TVDgo2gkb8Xhj3CvAdDg EyKb/yuQ1SpTUJST6LcuoCc20vKn2FJtXzuJPTDVRa68R/P534/tc5Hp9LtnjjwG/OMP qa7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ikk0Y+5uZfeA18JSc4isgoGR3s1LNR4eUH+lsA0taZs=; b=oJsJqEIcchjCE5FGdXBPHQlXzzyRUwuB50VD7c1kWf/DsYInHp8RwsLnTQJcQ7mBFk J4Y20TIP874E6A8AGoVc7fxNsYvBmnpds15aWggo/6iX90QReYV9/KmzoDa4jC0GATfO 3aLDWoaYCUXkGgNnQRtlfmTcEzotN+hkREMdbpzTXJK5R/ewdf6qZdXvhYjzznfh3+tV bywFay7pHWiWJTusgSK2zv9K3awyhHexGefJ9ftCL711zBv9O8Vj6IlPuLCPphSICSVA LaMUR/BDKvLT0xcNh/bkC/mApeOXRzu3U9xNtSRzqX9SLzom6pmo1Qn17MOTw3afm4kk vZpQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b14si44881947pgi.587.2019.08.05.19.42.40; Mon, 05 Aug 2019 19:42: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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731514AbfHFClP (ORCPT + 99 others); Mon, 5 Aug 2019 22:41:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35406 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729334AbfHFClP (ORCPT ); Mon, 5 Aug 2019 22:41:15 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 20FB9C0546F1; Tue, 6 Aug 2019 02:41:15 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-88.pek2.redhat.com [10.72.12.88]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E9365C1D4; Tue, 6 Aug 2019 02:41:12 +0000 (UTC) Date: Tue, 6 Aug 2019 10:41:08 +0800 From: Dave Young To: Ard Biesheuvel Cc: linux-efi , Kexec Mailing List , Linux Kernel Mailing List , Matthew Garrett , Bhupesh Sharma Subject: Re: [PATCH] do not clean dummy variable in kexec path Message-ID: <20190806024108.GA6956@dhcp-128-65.nay.redhat.com> References: <20190805083553.GA27708@dhcp-128-65.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 06 Aug 2019 02:41:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/05/19 at 06:55pm, Ard Biesheuvel wrote: > On Mon, 5 Aug 2019 at 11:36, Dave Young wrote: > > > > kexec reboot fails randomly in UEFI based kvm guest. The firmware > > just reset while calling efi_delete_dummy_variable(); Unfortunately > > I don't know how to debug the firmware, it is also possible a potential > > problem on real hardware as well although nobody reproduced it. > > > > The intention of efi_delete_dummy_variable is to trigger garbage collection > > when entering virtual mode. But SetVirtualAddressMap can only run once > > for each physical reboot, thus kexec_enter_virtual_mode is not necessarily > > a good place to clean dummy object. > > > > I would argue that this means it is not a good place to *create* the > dummy variable, and if we don't create it, we don't have to delete it > either. > > > Drop efi_delete_dummy_variable so that kexec reboot can work. > > > > Creating it and not deleting it is bad, so please try and see if we > can omit the creation on this code path instead. I'm not sure in this case the var is created or not, the logic seems tricky to me. It seems to me it is intend to force delete a non-exist var here. Matthew, can you comment here about Ard's question? > > > > Signed-off-by: Dave Young > > --- > > arch/x86/platform/efi/efi.c | 3 --- > > 1 file changed, 3 deletions(-) > > > > --- linux-x86.orig/arch/x86/platform/efi/efi.c > > +++ linux-x86/arch/x86/platform/efi/efi.c > > @@ -894,9 +894,6 @@ static void __init kexec_enter_virtual_m > > > > if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX)) > > runtime_code_page_mkexec(); > > - > > - /* clean DUMMY object */ > > - efi_delete_dummy_variable(); > > #endif > > } > >