From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 875DE48BD42 for ; Tue, 21 Jul 2026 12:06:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784635569; cv=none; b=UnIHSwcyqfKZ6T/159cZjrdnwJoLzt50jdWn6QCcD43OUmDRbrXcmIZdpk535AYa3kzAfrZp8iTwXpxud4plb6wI7ZezK+pCYZ86DENp32A1rbupNSAwtdB7xrQZpNVmDkkh6t0AernsiOmCVMKrVQOnUDpApB9FGef/dx26oQ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784635569; c=relaxed/simple; bh=3oupU7+5mQICPbOMW24bukRFFTm81wEOBpej2miz2tE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CNRCuxGbIa4xtKK2QB2zJmbTyxgChUkxZ3A/b7bOd0zxM51jqFhr5suMVwQQ2Ly2n7rn1F9xi8Iveyc8wHk3Eow7pQr5rSB3JRrGisQENNTTVhkFrx6gFLiQlLRv1fHMEY+5mtYgE1cV+iCQO1TSrJb7+slh9BMhd1hZtjRZwAs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=eZwE3YxB; arc=none smtp.client-ip=95.215.58.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="eZwE3YxB" Date: Tue, 21 Jul 2026 20:05:49 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784635564; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A7dYAlxy/AmMUyH+MlvfhyBiS8Q0C6HxH/Mauukj/gQ=; b=eZwE3YxBH34e9tRiCPggwYdYaOw6NhkKu6BTNStYMe942ZxlIFt9cE8RPfN+rNf2WBfllB dRtZZhVUmLMxoo5O5g9KDUWfGfoIsGLousnSIDCtVH38WaSJPywwXrv5D8cF+wN4+r7uBQ iKjh+SXv0L25Chs5leSM8+RdGynHSSE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Baoquan He To: Omar Sandoval Cc: Mike Rapoport , Pnina Feder , Simon Horman , Andrew Morton , Pasha Tatashin , Pratyush Yadav , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , Dave Young , Jonathan Corbet , Alexandre Ghiti , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org, linux-debuggers@vger.kernel.org Subject: Re: [PATCH 0/4] vmcore-tasks: export per-task metadata to vmcoreinfo Message-ID: References: <20260622211430.4008899-1-pnina.feder@mobileye.com> <20260720091927.GA1736709@horms.kernel.org> Precedence: bulk X-Mailing-List: linux-debuggers@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT On 07/20/26 at 10:35am, Omar Sandoval wrote: > On Mon, Jul 20, 2026 at 10:40:43PM +0800, Baoquan He wrote: > > On 07/20/26 at 03:43pm, Mike Rapoport wrote: > > > Hi Simon, > > > > > > On Mon, Jul 20, 2026 at 10:19:27AM +0100, Simon Horman wrote: > > > > On Tue, Jul 07, 2026 at 09:21:58AM +0300, Mike Rapoport wrote: > > > > > On Tue, Jun 23, 2026 at 12:14:26AM +0300, Pnina Feder wrote: > > > > > > This series extends vmcoreinfo with struct offsets and sizes needed by > > > > > > the vmcore-tasks userspace tool to extract per-task state from a vmcore > > > > > > dump without requiring kernel debug symbols (DWARF/BTF). > > > > > > > > > > > > The vmcore-tasks tool reads /proc/vmcore (or a saved vmcore file) and > > > > > > reconstructs, for each task: > > > > > > - task name, pid, state, flags > > > > > > - VMA list (start, end, flags, backing file) > > > > > > - user register state (saved on the kernel stack at kernel entry) > > > > > > - user-space backtrace with VMA/filename mapping > > > > > > - kernel dmesg buffer > > > > > > > > > > > > This provides a lightweight post-mortem crash analysis capability for > > > > > > production environments where full debug info (DWARF/BTF) is not > > > > > > available. > > > > > > > > > > > > The companion userspace tool is submitted to kexec-tools: > > > > > > https://lore.kernel.org/all/20260622205550.1087163-1-pnina.feder@mobileye.com/ > > > > > > > > > > Sorry for the delay, this fell between the cracks somehow. > > > > > > > > > > The kernel side looks fine overall, but to merge it there should be an > > > > > agreement from the userspace side maintainers that vmcore-tasks is > > > > > something they are wishing to accept. > > > > > > > > Hi Mike, all, > > > > > > > > Sorry for the extended delay. > > > > > > > > I will send some minor feedback to the user-space tool patchset > > > > but overall, yes, this is something I would be happy to accept. > > > > > > > > I don't want to create a chicken-and-egg type problem here. > > > > But it's probably worth mentioning that usually features > > > > hit the kernel before the corresponding code is accepted > > > > into kexec-tools. > > > > > > Sorry if I wasn't clear. > > > > > > I didn't mean that the feature should be merged into kexec-tools before > > > merging the kernel bits. I just wanted to make sure there's no fundamental > > > issue from kexec-tools perspective. > > > > > > > Let me know how you would like to proceed. > > > > > > I'm going to wait for Baoquan's review and once that's done I'll pick up > > > the kernel bits. > > > > Oh, sorry, I just noticed this series, but a quick look give me a hint > > of 'No, I don't like it.' We have had Crash utility, Drgn, now a new one > > comes up. I have some concerns to Pnina: > > > > 1. Exporting maple tree internals (maple_node, maple_range_64, > > maple_arange_64, maple_metadata) as vmcoreinfo ABI is problematic. > > These are private implementation details, not stable structures like > > task_struct. Any refactoring of the maple tree will silently break > > the userspace tool. > > > > 2. Without DWARF/BTF, the debugging scope is inherently limited — no > > kernel stack backtrace, no symbol resolution, no variable access. > > That's essentially "ps + /proc/PID/maps" from a vmcore. Have you > > considered enabling CONFIG_DEBUG_INFO_BTF on your platforms instead? > > BTF is compact (typically < 1 MB) and would give drgn full access > > without needing vmlinux debug packages. That seems like a better > > return-on-investment than maintaining ~40 new vmcoreinfo exports. > > > > 3. Beyond the technical concerns, I wonder about adoption. vmcore-tasks > > targets a fairly narrow use case — platforms without DWARF/BTF, where > > you still have vmcore but can't ship vmlinux. Is Mobileye currently > > the only consumer? Are you guys already using it widely and fully? > > If this lands but doesn't see broader uptake, the ~40 exports risk > > becoming dead weight in vmcoreinfo — nobody actively uses them, but > > kernel changes still need to keep them consistent, or they silently > > rot and give users wrong results. > > > > Regards, > > Baoquan > > (Adding linux-debuggers mailing list). > > I agree with all of Baoquan's points here, with a couple of notes: > > 1. drgn's BTF support is currently a work in progress, but it's shaping > up well: https://github.com/osandov/drgn/pull/625. > 2. makedumpfile is also gaining BTF extension support: > https://lore.kernel.org/all/20260617051834.95404-1-ltao@redhat.com/. > It's lighter-weight than drgn while still being much more general > than this series. Thanks for adding the information, very helpful.