Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3365802pxb; Mon, 17 Jan 2022 18:43:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJzIQW6yah+UEkuMVSinfmcXYXi4P++KByONnseICtb2WRSn3jR+5ZosAQvwa3qFo9tXXtUC X-Received: by 2002:a17:902:b681:b0:14a:9cc:d9a3 with SMTP id c1-20020a170902b68100b0014a09ccd9a3mr25435859pls.121.1642473792685; Mon, 17 Jan 2022 18:43:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642473792; cv=none; d=google.com; s=arc-20160816; b=X3wXHmsA/wT8Q21lKq15LCjoFq9M3CDqG9lQOZlL+4YPUSUPW7wDalbUZUXuV/UBOE KEEOoG4OrlN4xgLt7O0jdmFv/jcxzi63BQ4NlLVGfOT5fW8bVCFMDh1bfVP8c9o4RLCl QSZLRnYfhgOn0KVMQBR3R25Cr0DL8jgccndwav1LwjX2PiHV84dpNX+Xa+02DDqApBPu 6T7TogI4bV5FjVZAfJ0N/gx0Cy2Y4a2tVHUl1DAfJyInfdHJB+CnnxDSul0CgsJMr6yw /a7ETNHZ4BIL/LIYD4BP8n4wzEEaS4mMfzb2suL7UD+a8jSWah0Kav1EtxJi0HftCCqc Kjdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=FqzOFAGoqiarGZI3wvIr0L6nnfXp2ICFDfXfr4vu4Jw=; b=OgYBOgkJDAmS9wXauofR1W/5WjPen2f3ubOVSFxHDMI84Z9IYviUUH/VHkv4ZBR19x 7Xv6ful81x5yNjsmieWJT1ELPHNPm1FNoTY7CIyX5rng+P9as8OkKXNE4i4drtNO9Acd H60ckBHWf9+UWA3sinKIBIwecSsUmEfPsgNpCiIZAyJnuoQh6IsTfzEZu9L6nWeAm5Zr AEIpBukSeIBH3BJ+veCwBD5XWWwO0JeUuYBHEjRie7JcaqD/gIffCeRoUP6CinLUlGDz SoqGGhnyMeK5Z7c7f/W7tJgAYSQKi3NY4cjem568UEvPBVZe3q98QJcUefqB07CU6RHY RDqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SwVTAM0O; 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 h191si12762214pge.741.2022.01.17.18.42.58; Mon, 17 Jan 2022 18:43:12 -0800 (PST) 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=k20201202 header.b=SwVTAM0O; 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 S241793AbiAQRAx (ORCPT + 99 others); Mon, 17 Jan 2022 12:00:53 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48086 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241548AbiAQRAJ (ORCPT ); Mon, 17 Jan 2022 12:00:09 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 432CAB8114B; Mon, 17 Jan 2022 17:00:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7ACD9C36AEC; Mon, 17 Jan 2022 17:00:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642438806; bh=SCgLEX0Kh7icKYxXAHJBDyBvz8vlCwfQ+JaNq8HYN6I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SwVTAM0O0Mvyo449Rh7NDLSXe7Eqs5/bVok17XX3DujawY6cmkU6Kcp1K2EwzmFMb 6uW/egpt6v9mYfim9ZzwjmQxv2qmnYD5/K8aPHjEtVtQbzbStrMG34YP5kKt5X7vMC 62OXMsqBjntQ5sTiatwkonhHk1/GQ8QjTsUS4DW+dZ++5k0gpaxm5VFP1ylwdf10DC zldBk7LWIp3T2NRv15uJfODB6FA0HGNAv11TB4/RXP94SgJpNZiUmUvf/E1qgqw9TE hbmD39JARcIE0As0G4Gbi7Sdyju6/2cAfPi4WzW1sKGUk758rLRfOpDqBqteKoKGZm 6iwa5bfSBnJ4A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hari Bathini , kernel test robot , Michael Ellerman , Sasha Levin , srikar@linux.vnet.ibm.com, ego@linux.vnet.ibm.com, nathanl@linux.ibm.com, clg@kaod.org, parth@linux.ibm.com, npiggin@gmail.com, robh@kernel.org, yukuai3@huawei.com, linuxppc-dev@lists.ozlabs.org Subject: [PATCH AUTOSEL 5.16 29/52] powerpc: handle kdump appropriately with crash_kexec_post_notifiers option Date: Mon, 17 Jan 2022 11:58:30 -0500 Message-Id: <20220117165853.1470420-29-sashal@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220117165853.1470420-1-sashal@kernel.org> References: <20220117165853.1470420-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Hari Bathini [ Upstream commit 219572d2fc4135b5ce65c735d881787d48b10e71 ] Kdump can be triggered after panic_notifers since commit f06e5153f4ae2 ("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump after panic_notifers") introduced crash_kexec_post_notifiers option. But using this option would mean smp_send_stop(), that marks all other CPUs as offline, gets called before kdump is triggered. As a result, kdump routines fail to save other CPUs' registers. To fix this, kdump friendly crash_smp_send_stop() function was introduced with kernel commit 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump friendly version in panic path"). Override this kdump friendly weak function to handle crash_kexec_post_notifiers option appropriately on powerpc. Reported-by: kernel test robot Signed-off-by: Hari Bathini [Fixed signature of crash_stop_this_cpu() - reported by lkp@intel.com] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211207103719.91117-1-hbathini@linux.ibm.com Signed-off-by: Sasha Levin --- arch/powerpc/kernel/smp.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index aee3a7119f977..7201fdcf02f1c 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -620,6 +620,36 @@ void crash_send_ipi(void (*crash_ipi_callback)(struct pt_regs *)) } #endif +#ifdef CONFIG_NMI_IPI +static void crash_stop_this_cpu(struct pt_regs *regs) +#else +static void crash_stop_this_cpu(void *dummy) +#endif +{ + /* + * Just busy wait here and avoid marking CPU as offline to ensure + * register data is captured appropriately. + */ + while (1) + cpu_relax(); +} + +void crash_smp_send_stop(void) +{ + static bool stopped = false; + + if (stopped) + return; + + stopped = true; + +#ifdef CONFIG_NMI_IPI + smp_send_nmi_ipi(NMI_IPI_ALL_OTHERS, crash_stop_this_cpu, 1000000); +#else + smp_call_function(crash_stop_this_cpu, NULL, 0); +#endif /* CONFIG_NMI_IPI */ +} + #ifdef CONFIG_NMI_IPI static void nmi_stop_this_cpu(struct pt_regs *regs) { -- 2.34.1