From nobody Fri Nov 1 01:11:51 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 4XfjWF1YgKz5bHpg; Fri, 01 Nov 2024 01:11:53 +0000 (UTC) (envelope-from jhibbits@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 4XfjWF0dhmz4Krw; Fri, 1 Nov 2024 01:11:53 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730423513; 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=UCbfWZBo6vDa1tkge/31CJ0yV6YoudWvtuNpzz/RRPg=; b=aBLKVCck3BAMYNym4vKwj9yyCJC+4reYcgwsHhSeofO9huR8wJzLUc5s6q1v92nnDzZ4db uwdHoClUXbaoMvBEDTEQqxkz249EOUBqrGHgHLrH8phcUD5kw/43fldNXNFYC4y2ypvuWa eXKVdP0TtguVUWe18mElKZzYc/UowTo+tV1OwPTVJdU7oxuFvfHCAnLg7YBvOhcvibwa1r 9BSdVIQIHilL6GaALS4lJ/b+ZaizduedQUFxYmtlOPtqgt9aeyn1LGr18NDToYmVto4b0I 9AhlFAGPefTqO4EJEc2jmUa96uekulMOCvtfY65BjsTdQ/5Rpq6/E8ityMomXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730423513; 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=UCbfWZBo6vDa1tkge/31CJ0yV6YoudWvtuNpzz/RRPg=; b=ugQWYuHmbOG8v/nBKSgfh4Vkk7uE/hGWyDPKkk797psnCIbhO6S1BE6XGH2+5kuPF8G/bA 9uzs7ykQ7kH8poGZyoq4MlpvdvGEXyktEKyodIYQFZO90sZQx5rJRd9eqV7may2815h4jX CpfGzgavZaHAtSv74GnSg2Ft98IseInzM/YWZXRDzoseHtPf2ANwSnYeSCv7csQ7xzcMSR 0XOdeMWMlKqDQUBRZ1ZdF5tQGiGFPSrKTv/DFor7CVreIaK9+DRiVBkcOzTD6QE8QyTukj 85qDdtSW2s+MbVJVa26olccvIEpXWX8v/BpDD0fKNClXCx8Bq4W9TarNbkwcnQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730423513; a=rsa-sha256; cv=none; b=YNnrjzv8CX2cb9TfiTcA26NitE05hurHmcAKOZRklXpFE/SG6VGkTn3VckXODcJWX0GpRS ke1/RK1FNbMmnOdmsq+1RKotKbWGqhNRKtVudy27v7YwH70xn+UdaaoqGVJz9LI6EDlSvU oRePaSe2MYlhH9XVSJH7TwQO4cr997QqPYRT0g2SNCUDi9nmqxB3D7L+IQcJDuetMCjuN/ Eyaavu9V2cE9AuPqjEEHpOrbUPgXX+j2CPHlmSMLZDFhZCCxt/picw9RQCuOVM4pNkboJn UQ9oLQfqJfEBDidgqMkbidJXsLA3hzCu7sFKIiWz+f8OONgpT639amwh0wJwvg== Received: from ralga.knownspace (unknown [IPv6:2600:2b00:a720:d301:9f03:382a:d672:81f0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhibbits) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XfjWD6S4rz1HQ2; Fri, 1 Nov 2024 01:11:52 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Thu, 31 Oct 2024 21:11:51 -0400 From: Justin Hibbits To: Warner Losh Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Direct dumped kernel cores Message-ID: <20241031211151.795eba3e@ralga.knownspace> In-Reply-To: References: <20241031182354.14fa48aa@ralga.knownspace> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; powerpc64le-unknown-linux-gnu) 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 On Thu, 31 Oct 2024 16:32:51 -0600 Warner Losh wrote: > On Thu, Oct 31, 2024 at 4:24=E2=80=AFPM Justin Hibbits > wrote: >=20 > > 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`. > > =20 >=20 > First off, this is kinda cool. I've wanted this occasionally when my > swap partition is too small (though in my case, it was easy enough to > add another drive to the system that was panicking and dump to that). >=20 > I do have a question: I'm curious why you didn't follow the Linux > lead of having > a kexec_load(2) system call to load the 'rescue kernel' to make this > more generic. > That would make the leap to having full kexec support (eg > reboot(CMD_KEXEC) a lot easier to implement. >=20 > Warner One problem with trying to kexec_load() a rescue kernel is that the rescue kernel needs its own memory to work with, a contiguous block, so needs to be loaded early, or at least reserved early. Without its reserved memory it would be stomping over the 'host' kernel's memory. That said, I do like that direction, and it's definitely worth exploring. - Justin >=20 >=20 > > There are many more details in the review summary. > > > > We'd love to get feedback from anyone interested. > > > > Thanks, > > Justin Hibbits > > > > =20