Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2375826ybl; Thu, 19 Dec 2019 12:29:30 -0800 (PST) X-Google-Smtp-Source: APXvYqzpfcuWG+zwB4Jhuir4mstNZJM8XWvuqp2vat4tpm2dqhCaHzaSN+sG2uvUlUJAwt7rVDc1 X-Received: by 2002:a05:6830:2098:: with SMTP id y24mr11021841otq.312.1576787370112; Thu, 19 Dec 2019 12:29:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576787370; cv=none; d=google.com; s=arc-20160816; b=lREeSMF0yWXfPOwUG9R/OxRFeoOVKzQxz8kh2yRIhCW0oRbv6Nw62GcfEOjmCH5XMo bzHKlqLQMw+RyP8Xvzex8HkcQGt0Xxo8Qz0/+UsdvdZErRquFpmriwgiJdbp8k8Vx9sJ 8WbwTO/nnc7KiZjrr/kcleLiM7XoiylaOy7HOkbmzHXdtqLVH8SrH2zfcDcTSA9Z1MLa AQMimdqcrIOReEHw0owjKyINRWbr3Kj24XuPzKYxMLaQCv6yJs/VboF90MnKo6YH2TGN QDblv2XFY7N5EVEZefNqU7JwXe9gu8572c2oe76y2SPoUPXXNS1j4k6SOjG0uau1jskT W4eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=iYkVZqyXvPlx+fIEnulqGYvT8K8hQvvLGTRkxC+sfqQ=; b=ycG2+whKX3acn4AumOvti3gGuYToTPkAZDjqp7gj/rO95pdQAYAhuCWtPsJAYavZMx uxCZ4XgqalThp0ZR6bd5yE7CBKxyGn4k2X9TQ8HyU0lBb+EkLUDyc2v9xpCT94mVT3y/ PDFxd0vRIyK2Fk6uKck/VkIPhCujT6GJz/oKxUj3mQq3iQkC7oJLXuvK41psxKFVa+XG 9fvwuc3CpUfj194J2TPFCbJXGbLhHxFHHA8y7Bbxnk1OXv8dtlubBsdni9Qe8EmXu5w9 EMBWJUzbdLLkFIkX6vKiBh6EvaZbk22l6N6IWZBNlpGGeTFzif9U9UOBTNXAHlr/28LF 5feQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@osandov-com.20150623.gappssmtp.com header.s=20150623 header.b="Ph++/qrA"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e25si798277oie.146.2019.12.19.12.29.19; Thu, 19 Dec 2019 12:29:30 -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; dkim=pass header.i=@osandov-com.20150623.gappssmtp.com header.s=20150623 header.b="Ph++/qrA"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727179AbfLSU2K (ORCPT + 99 others); Thu, 19 Dec 2019 15:28:10 -0500 Received: from mail-pl1-f194.google.com ([209.85.214.194]:33122 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726869AbfLSU2K (ORCPT ); Thu, 19 Dec 2019 15:28:10 -0500 Received: by mail-pl1-f194.google.com with SMTP id c13so3092459pls.0 for ; Thu, 19 Dec 2019 12:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iYkVZqyXvPlx+fIEnulqGYvT8K8hQvvLGTRkxC+sfqQ=; b=Ph++/qrA450zlZKpiEEsHQkhDtqwSwglWc77UJZ8pmMlVmX1g5boEaiatKqfGfTfNn QYBFt9Shna2KWx0iLva3l99HN2xerVQP8pp1R2paOTl3f11LFpOaQlaKvYRgli3nA4wc 1s/ZgEfSYOernV8HzkjcBOimOwQzM0ZgDSJlb42clm7HD5l60Fe4NfUcVEcBY3QBEVCF N8Ve/yIdVF4FxE+wWa3dHn+t3eWAXfLyz4yTAkDrFovRMWcFQpDnd3GHexeyL2tdaS7J pYpSzBcYjQjI2kLb6jvfaXb+0YQKblFtHdE8mScAerr7JSA3kRbHvnyKUXejwfXVJuvM 0RLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=iYkVZqyXvPlx+fIEnulqGYvT8K8hQvvLGTRkxC+sfqQ=; b=cZKLaFVuGp8OW2fmcZYtaoAZMT5j4Jxn1022rPMYax6/IfI4dT+8M1gwpMGwVOlWIp Nuc1uPxJitKzfruhR3BfGJzj7UZ4CNQk9bvGNtKe3mP9jPGeDT41gcsVlNBjrGyzUZ4T L2lxl2/5ldqn2SOX0T91x2FImYqA7+g95OFtY5kKlbo6Na6t+BT4m++3fCBM0gVOCrCZ pwOwWk8ytpbKyvajs4wGn32jRiCQQp0Dass6jD1rcLc/KuZmehDx0PyGka5Gujvh92gk soVgFkjLM9uyOM6U7Lbm12bW5jdE3i2UhLoYLqarC119SbPoeRz8UY0F/qMQbiaLLAv9 HbvQ== X-Gm-Message-State: APjAAAUamld5m71PRTo2zZ3JFgnCoFszzLoIj4QOU3VC64XpwEatBsoE swlsHqA4NEuZRf0+ADW8ZCO/IA== X-Received: by 2002:a17:902:6544:: with SMTP id d4mr11307470pln.278.1576787288997; Thu, 19 Dec 2019 12:28:08 -0800 (PST) Received: from vader ([2601:602:8b80:8e0:e6a7:a0ff:fe0b:c9a8]) by smtp.gmail.com with ESMTPSA id m3sm5321973pfh.116.2019.12.19.12.28.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Dec 2019 12:28:08 -0800 (PST) Date: Thu, 19 Dec 2019 12:28:07 -0800 From: Omar Sandoval To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: define arch_crash_save_vmcoreinfo() if CONFIG_CRASH_CORE=y Message-ID: <20191219202807.GA826140@vader> References: <9e9eb78c157d26d80f8781f8ce0e088fd12120b4.1575309711.git.osandov@fb.com> <20191218104113.GB24886@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191218104113.GB24886@zn.tnic> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 18, 2019 at 11:41:13AM +0100, Borislav Petkov wrote: > On Mon, Dec 02, 2019 at 10:02:29AM -0800, Omar Sandoval wrote: > > From: Omar Sandoval > > > > kernel/crash_core.c calls arch_crash_save_vmcoreinfo() to get > > arch-specific bits for vmcoreinfo. If it is not defined, then it has a > > no-op fallback. kernel/crash_core.c is gated behind CONFIG_CRASH_CORE. > > However, x86 defines arch_crash_save_vmcoreinfo() in > > arch/x86/kernel/machine_kexec_*.c, which is gated behind > > CONFIG_KEXEC_CORE. So, a kernel with CONFIG_CRASH_CORE=y and > > CONFIG_KEXEC_CORE=n > > How does that even happen? > > Symbol: KEXEC_CORE [=y] > Type : bool > Defined at arch/Kconfig:17 > Selects: CRASH_CORE [=y] > Selected by [y]: > - KEXEC [=y] > - KEXEC_FILE [=y] && X86_64 [=y] && CRYPTO [=y]=y && CRYPTO_SHA256 [=y]=y > > In order to do crash dumps, you need to select KEXEC, which selects > KEXEC_CORE, which selects CRASH_CORE... > > Or are you talking about the PROC_KCORE use angle where it selects > CRASH_CORE and the crash_save_vmcoreinfo_init() initcall is then > supposed to save arch-specific crash info? Yes, I'm talking about reading VMCOREINFO from /proc/kcore at runtime, no kdump involved. crash [1] and my own tool, drgn [2], use this for live debugging. I can set CONFIG_PROC_KCORE=y, which selects CONFIG_CRASH_CORE=y, but if CONFIG_KEXEC_CORE=n, the VMCOREINFO is incomplete. 1: https://github.com/crash-utility/crash/commit/60a42d709280cdf38ab06327a5b4fa9d9208ef86 2: https://github.com/osandov/drgn/blob/73dd7def1217e24cc83d8ca95c995decbd9ba24c/libdrgn/program.c#L385