Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3289462imb; Tue, 5 Mar 2019 05:54:41 -0800 (PST) X-Google-Smtp-Source: APXvYqyMVnw3c1igwRa+DbXDJVH1iVSDkygZeVna1o17NOqVj8SiYxJMBcnnyTts3Q1e/NffTeRF X-Received: by 2002:a62:3001:: with SMTP id w1mr1964918pfw.59.1551794081160; Tue, 05 Mar 2019 05:54:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551794081; cv=none; d=google.com; s=arc-20160816; b=ZCzqJXb4J7Oqt9TalpEkM7PK2JOpqwyZob9X6Jea1iEyUwxOZUsexKT7CiyIMnYUw0 f9boUwtGMCJ94u5EkemWgh4VRwWd2SgElGCCFhAAjaJX9d6NcrCM8uI33iKPb8L/Uvoo YU5Y5/6JB4/ZKSY6or6T4k/9HET3XmFOZpRpJEwt5NMiNF5SW9fdDkvCrr6X6p1XyTBj mnPWXqYQn21WvOTTg44ML3hcc4oIqFg5AqXQ+/AJLdzQlsRsq1d8sl2g+CWVcsmkBVsx C9GdWPMpaOz+4gBnYUGR3Um9x9Cd4Bfqp+pS9TIQfEZQkJVt0yaTAtlhYy57OR8Qoxip ZYfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=KFblqitCS/t9/zio8t3tHEgSKVfGGKkMm/sFRhI8NdQ=; b=yHp5sKZ1SAJJj4ejBYJwsXrUgf8Leyxo/6TV7s1HY41fMTNOxB+DZA7g10EpUMkzEA ctTWqM/iOB14qn7RNKg2TMflNoHYpw5U/KGo6Sn+hz8EAV9PLPeC4VPqOJybHldFk0It UYSiMvqf8BQtb7r7k3jPCtMORbkfjS+pHuUf+GTusrTx75Y1pas68s822/fQlGHxLsZJ gjOdM2UMNfdjvt74VYIk8Qe4pey3vnvztMTqmyeS+1E1EC8KRaIJoLW/P30xqzu+iXK9 bdMkdSo5mDpb1IVFsaohkACPQLuHqIXmq6FsdUBdi9H7dY8Vo1rleeZjw8vt7bCatNsI FJmw== 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 j16si8044621pgk.441.2019.03.05.05.54.25; Tue, 05 Mar 2019 05:54:41 -0800 (PST) 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 S1728054AbfCEMRu (ORCPT + 99 others); Tue, 5 Mar 2019 07:17:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55248 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbfCEMRt (ORCPT ); Tue, 5 Mar 2019 07:17:49 -0500 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 06768309264C; Tue, 5 Mar 2019 12:17:49 +0000 (UTC) Received: from kasong-laptop-rh.nay.redhat.com (unknown [10.66.128.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id 09586171AC; Tue, 5 Mar 2019 12:17:41 +0000 (UTC) From: Kairui Song To: linux-kernel@vger.kernel.org Cc: "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Sasha Levin , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Vitaly Kuznetsov , Dave Young , x86@kernel.org, devel@linuxdriverproject.org, Kairui Song Subject: [PATCH v2] x86, hyperv: fix kernel panic when kexec on HyperV Date: Tue, 5 Mar 2019 20:17:03 +0800 Message-Id: <20190305121703.29769-1-kasong@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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.43]); Tue, 05 Mar 2019 12:17:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org After commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments"), kexec will fail with a kernel panic like this: kexec_core: Starting new kernel BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 8000000057995067 P4D 8000000057995067 PUD 57990067 PMD 0 Oops: 0002 [#1] SMP PTI CPU: 0 PID: 1016 Comm: kexec Not tainted 4.18.16-300.fc29.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v3.0 03/02/2018 RIP: 0010:0xffffc9000001d000 Code: Bad RIP value. RSP: 0018:ffffc9000495bcf0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffc9000001d000 RCX: 0000000000020015 RDX: 000000007f553000 RSI: 0000000000000000 RDI: ffffc9000495bd28 RBP: 0000000000000002 R08: 0000000000000000 R09: ffffffff8238aaf8 R10: ffffffff8238aae0 R11: 0000000000000000 R12: ffff88007f553008 R13: 0000000000000001 R14: ffff8800ff553000 R15: 0000000000000000 FS: 00007ff5c0e67b80(0000) GS:ffff880078e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000001cfd6 CR3: 000000004f678006 CR4: 00000000003606f0 Call Trace: ? __send_ipi_mask+0x1c6/0x2d0 ? hv_send_ipi_mask_allbutself+0x6d/0xb0 ? mp_save_irq+0x70/0x70 ? __ioapic_read_entry+0x32/0x50 ? ioapic_read_entry+0x39/0x50 ? clear_IO_APIC_pin+0xb8/0x110 ? native_stop_other_cpus+0x6e/0x170 ? native_machine_shutdown+0x22/0x40 ? kernel_kexec+0x136/0x156 ? __do_sys_reboot+0x1be/0x210 ? kmem_cache_free+0x1b1/0x1e0 ? __dentry_kill+0x10b/0x160 ? _cond_resched+0x15/0x30 ? dentry_kill+0x47/0x170 ? dput.part.34+0xc6/0x100 ? __fput+0x147/0x220 ? _cond_resched+0x15/0x30 ? task_work_run+0x38/0xa0 ? do_syscall_64+0x5b/0x160 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables sunrpc vfat fat crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_rapl_perf hv_balloon joydev xfs libcrc32c hv_storvsc serio_raw scsi_transport_fc hv_netvsc hyperv_keyboard hyperv_fb hid_hyperv crc32c_intel hv_vmbus That's because now we may use hypercall for sending IPI, the hypercall page will be reset very early upon kexec reboot, but kexec will need to send IPI for stopping CPUs, and it will reference this no longer usable page, then kernel panics. To fix it, simply reset hv_hypercall_pg to NULL before the page is reset to avoid any misuse, IPI sending will fallback to use non hypercall based method. This only happens on kexec / kdump so setting to NULL should be good enough. Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments") Signed-off-by: Kairui Song --- Update from V1: - Add comment for the barrier. arch/x86/hyperv/hv_init.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 7abb09e2eeb8..34aa1e953dfc 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -406,6 +406,12 @@ void hyperv_cleanup(void) /* Reset our OS id */ wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0); + /* Cleanup hypercall page reference before reset the page */ + hv_hypercall_pg = NULL; + + /* Make sure page reference is cleared before wrmsr */ + wmb(); + /* Reset the hypercall page */ hypercall_msr.as_uint64 = 0; wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); -- 2.20.1