From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CEBA2C2BB1D for ; Sat, 18 Apr 2020 00:46:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A6591221EA for ; Sat, 18 Apr 2020 00:46:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587170818; bh=14qSYdrLemwVEC2uAz97e2xRaw+5yWSJoO7bWCN/K+M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=KnRPtgodEDjl0vMAyxih5dPeqk8s59FCEGKwm/itr6keC5j6qG13UhK4+kVTcMaun ArtcJ+cvGNOqHha5xdt8ea/vUCfh8qatO7RFTuUaQw38bVs8eAsB0QK6T+ApXcgP2Y KWQHkmzCd99MRDOmRO+cxfGqvGuPbR3YnSLjNvf4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725873AbgDRAq4 (ORCPT ); Fri, 17 Apr 2020 20:46:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:53136 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725867AbgDRAq4 (ORCPT ); Fri, 17 Apr 2020 20:46:56 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2E767214D8; Sat, 18 Apr 2020 00:46:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587170815; bh=14qSYdrLemwVEC2uAz97e2xRaw+5yWSJoO7bWCN/K+M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=yxkA8fcXsZ3kHBWGVChkWfhLXCziPW7a3jxL/C2RqnxvOCRPknlE3ur4ow8QKyd1C KRYzLVsbvXBu5n4P5eslol7AvQWnzw0Lxwn2EEBNGYbRtXL0EHdnqPh9H05MLVrh4w FNWiKKtyNJWl/oZBQwCLwS+px7QRgKEm1hk2sSi8= Date: Fri, 17 Apr 2020 17:46:54 -0700 From: Andrew Morton To: "Guilherme G. Piccoli" Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, tglx@linutronix.de, vbabka@suse.cz, rdunlap@infradead.org, willy@infradead.org, kernel@gpiccoli.net Subject: Re: [PATCH V3] panic: Add sysctl to dump all CPUs backtraces on oops event Message-Id: <20200417174654.9af0c51afb5d9e35e5519113@linux-foundation.org> In-Reply-To: <20200327224116.21030-1-gpiccoli@canonical.com> References: <20200327224116.21030-1-gpiccoli@canonical.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, 27 Mar 2020 19:41:16 -0300 "Guilherme G. Piccoli" wrote: > Usually when kernel reach an oops condition, it's a point of no return; > in case not enough debug information is available in the kernel splat, > one of the last resorts would be to collect a kernel crash dump and > analyze it. The problem with this approach is that in order to collect > the dump, a panic is required (to kexec-load the crash kernel). When > in an environment of multiple virtual machines, users may prefer to > try living with the oops, at least until being able to properly > shutdown their VMs / finish their important tasks. > > This patch implements a way to collect a bit more debug details when an > oops event is reached, by printing all the CPUs backtraces through the > usage of NMIs (on architectures that support that). The sysctl added > (and documented) here was called "oops_all_cpu_backtrace", and when > set will (as the name suggests) dump all CPUs backtraces. > > Far from ideal, this may be the last option though for users that for > some reason cannot panic on oops. Most of times oopses are clear enough > to indicate the kernel portion that must be investigated, but in virtual > environments it's possible to observe hypervisor/KVM issues that could > lead to oopses shown in other guests CPUs (like virtual APIC crashes). > This patch hence aims to help debug such complex issues without > resorting to kdump. > > ... > > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -513,6 +513,12 @@ static inline u32 int_sqrt64(u64 x) > } > #endif > > +#ifdef CONFIG_SMP > +extern unsigned int sysctl_oops_all_cpu_backtrace; > +#else > +#define sysctl_oops_all_cpu_backtrace 0 > +#endif /* CONFIG_SMP */ > + hm, we have a ton of junk in kernel.h just to communicate between sysctl.c and a handful of other files. Perhaps one day someone can move all that into a new sysctl-externs.h.