From nobody Thu Oct 31 22:33:39 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Xff0l4yg8z5b2mv; Thu, 31 Oct 2024 22:33:43 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xff0l4Jfpz40v8; Thu, 31 Oct 2024 22:33:43 +0000 (UTC) (envelope-from rpokala@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730414023; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QUzbJs+AL9SLoQCEzfTEkA2UcHhGE2Gu44JLMQh/ZO8=; b=V6Z07h3dU2NOoNlmLNmxkP0ccxv3X7PVk6Ka4LHA+fy9Gn3cMNlP4bJifG0AbzrQBeFihf J/jspbbKKexLYdFm3bua2xsAMHlZZcp6Yrll7ZbO96kFbIWU7GaxSYMWzxVb6HFjnj4F2W JbwqtzLApZUEO3capo3A2ayzsA6hs38q+q6ga+I8TKW0bPHtHlJ2OY5MybDDfhjq4Zx3Be sLZiYwcfI+3wTwYbisXpykpWbBDk/Dm28zo1gumKsYpHX3AiRBuDNnvtoWV12V5tDOns9Z fknqbVCEwmgF98CwYTn+nctyqx+drNr8fy773XWf40ZhaJq+99o5f8a0vrL4aA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730414023; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QUzbJs+AL9SLoQCEzfTEkA2UcHhGE2Gu44JLMQh/ZO8=; b=RtQ1/vKqI6l9SshZWYQXmxs+nzy6OCJlCRWiTrjdrBXUm/CWBTpFA4zsZUhNavaD5+S+kf 7+6uOhZLq7ZrrAL7XfbI7cFA+tJj+0U6xMgc0gfv3z+iMCASCRsgyx/i4HRip6WqSWY25a 78AFHINN+LCHmrSc+C3FKOU7Cv4SIbyhUL8se9GFx7v5aJnavQJBzHxsSJmJf/D8JM8qLQ YuP+4J16N1ldN2MuLyLppfYsqajXkBgN2RHy4sXRpE6yA2hF/byCX6kySZUvYtYM8oUjGv iW6C54sSbU2W9ZiuOKWME9o992W6dfm8tELsR4zKqpQTsYNKOalkTsRW/1L8Eg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730414023; a=rsa-sha256; cv=none; b=VMSKMoTqR7CgPKLSmxLluZFWDu8EhMC+90netp4LtZu/dQQHuOF3K2oy4tTlODI2L1wFML h3PMhRCwsWFSuHdNb91XyRPCtEJ1i/J96kaA+RvPKPubDEB7EH94itRSph37L5ipk6woog qnaWnMuIX8j9cT9WgFzQhSgY6p7PEwqGwMKoDR3p5sHlU5TMmMEl54UiOqviTz1SqTd3rD ZiH+ka6UgqfIq//FXiIn/I0QQZ2vkFwO7cxPsDUHLKDSTqQ8pOWfHw2BPopLrZO0UAgmi0 3j7OPu+EzkSFtuZyfg31naFiE57E3nMgOQWy1BhwGA++ca/2mVRkPg1L4k8GsQ== Received: from [192.168.1.10] (c-73-231-46-254.hsd1.ca.comcast.net [73.231.46.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Xff0l0Mt6z1FSD; Thu, 31 Oct 2024 22:33:42 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/16.90.24102719 Date: Thu, 31 Oct 2024 15:33:39 -0700 Subject: Re: Direct dumped kernel cores From: Ravi Pokala To: Justin Hibbits , , Message-ID: <63B5260F-C835-4BFF-92ED-767AD0CEFE05@panasas.com> Thread-Topic: Direct dumped kernel cores References: <20241031182354.14fa48aa@ralga.knownspace> In-Reply-To: <20241031182354.14fa48aa@ralga.knownspace> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Justin, So, this is like the 'crashkernel' thing Linux has, where it kexec()s an al= ternate kernel when the main one panics? I haven't looked at the patch -- most of it will be way out of my expertise= -- but what, if anything, is done to make sure the on-disk state of the tar= get filesystem is okay, before the "rescue" kernel starts writing to it? Thanks, Ravi (rpokala@) =EF=BB=BF-----Original Message----- From: > on behalf of Justin Hibbits > Date: Thursday, October 31, 2024 at 15:23 To: >, > Subject: Direct dumped kernel cores Hi everyone, At Juniper we've been using a so-called 'rescue' kernel for dumping vmcores directly to the filesystem after a panic. We're now contributing this feature, implemented by Klara Systems, to FreeBSD, and looking for feedback. I posted a review at https://reviews.freebsd.org/D47358 = for anyone interested. Interesting bits to keep in mind: * It requires a 2-stage build process, one to build the rescue kernel, the other to build the main kernel, which embeds the rescue kernel inside its image. This might need some further work. * Thus far it's been implemented for amd64 and arm64, once proven out, other architectures (powerpc64/le, riscv64) can follow suit. * Kernel environment bits to pass down to the rescue kernel are prefixed `debug.rescue.`, for instance `debug.rescue.vfs.root.mountfrom`. There are many more details in the review summary. We'd love to get feedback from anyone interested. Thanks, Justin Hibbits