From nobody Fri Nov 1 01:39:41 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 4Xfk7Z0r71z5bMLT for ; Fri, 01 Nov 2024 01:39:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xfk7Y66xqz4PLY for ; Fri, 1 Nov 2024 01:39:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-71e70c32cd7so1218408b3a.1 for ; Thu, 31 Oct 2024 18:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1730425192; x=1731029992; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JQ+kIjupGU6iGTXg9KApbOdVYwdm9wanbRyqQf8riE4=; b=1V7gakLFoyPar32jhn3XrD3bE1ghrB2H4yGt3UUykPyGxqCKX4bk4rh+nLtaetj1KV 8/c2HESIgETEeA4FvRg4GwG9OUPGkQOGK+ls5TfiOu4NEJparS4gSd8tQ9NQ7lF4M9qU 4O7rHsGaA3zlzu5CUjSrtST5g2dgPJUFcFldj0RvUaLTCljyaAxMpJFRS6a50W7V5Woz Yu3/n56JgJRZfcxSXARZFkgef7RDtY2v+rDIAUbndxsVFSy2cyeFD5JSV936WV+ENpvN 1qCZnBaWvnzaeBamLEH35xqkdMsVgsUTzIvXG6zCZ+fLhvbRJ98WCBGogNYzi6WRpuHS p7DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730425192; x=1731029992; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JQ+kIjupGU6iGTXg9KApbOdVYwdm9wanbRyqQf8riE4=; b=b2X4E34LQVSTpECRjrzSmwipzzZOXeyd5hD6caiqNPtUNuUxUyyFZt+iS4aBxH8QOC haS60/0ujQ8dh8kWOXoIrImqRMMY2n/cGEy/IVvDIOU1tX9+0asPEezGPTsIE1nipoTl JBe3RKmwG4yaSc+0MwkaSLIaX7Fb8+K8wwPwCke0LcAXtri3cS8oY71l7xtZlkXwgxC/ BB/1cO52+pq+UXbm3OcIw54vUtiZau/3TYsHW3bH/Xjvk3AFwxB4xlqhgkYFSrcliWh/ YSkHISU3YZHChTZ1qqG9Bf/u05xZgSiwsd+kTs0/yXNHqrKs6KHIEi98CSp45tESHmDK jFQg== X-Forwarded-Encrypted: i=1; AJvYcCUc26V82luzmcOv4jsbVbzUOcjRuXEsdWcoODek5YgKdkuGo8QlXeOpZZwWxrz/pVFUOljelzdBucv17msPw3A=@freebsd.org X-Gm-Message-State: AOJu0Yy8+TBVjU5aKXviYarKSamSQ6RMlw56RLZKmCol9rlRaejWJU5X XCk0SwRg4/g5OmUZh1p2ffRusH/0OyognJ+5hB6KOviF/52yBuRgmjLnk6wbo1ufNn3rvj9ABcn XBCqyd27CEnvRAdNXHx3dS4qZNS2IZ+eu7f6THA== X-Google-Smtp-Source: AGHT+IGgFogaCt9ytVMbIEnJPZfnnuf1LzPl8Kls1WnTSFbgacVQz3DvMEBWHCwr6kXtehHNw2/BcWGRrXXh9rojgWI= X-Received: by 2002:a05:6a20:d8b:b0:1cf:3d14:6921 with SMTP id adf61e73a8af0-1d9a84d168emr29256835637.35.1730425192501; Thu, 31 Oct 2024 18:39:52 -0700 (PDT) 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 References: <20241031182354.14fa48aa@ralga.knownspace> <63B5260F-C835-4BFF-92ED-767AD0CEFE05@panasas.com> <20241031210734.283a2fb5@ralga.knownspace> In-Reply-To: <20241031210734.283a2fb5@ralga.knownspace> From: Warner Losh Date: Thu, 31 Oct 2024 19:39:41 -0600 Message-ID: Subject: Re: Direct dumped kernel cores To: Justin Hibbits Cc: Ravi Pokala , FreeBSD Hackers , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000e9054b0625d00238" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Xfk7Y66xqz4PLY X-Spamd-Bar: ---- --000000000000e9054b0625d00238 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 31, 2024, 7:07=E2=80=AFPM Justin Hibbits = wrote: > On Thu, 31 Oct 2024 15:33:39 -0700 > Ravi Pokala wrote: > > > Hi Justin, > > > > So, this is like the 'crashkernel' thing Linux has, where it kexec()s > > an alternate kernel when the main one panics? > > If your description is accurate, then probably. I don't know if the > crashkernel thing from Linux existed when this was started, and > actually hadn't even heard of it until now. > Yeah. There's three types of kernels: debug, crash, and replacement. > > > 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 target filesystem is okay, before the "rescue" kernel > > starts writing to it? > > Good question. The rescue kernel embeds its own small rootfs it fscks > the target fs before writing to it. > Yea. My loader.kboot loads the kernel and initrd too... Warner > - Justin > > > > > 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 > > > > > > > > > > > > > > > --000000000000e9054b0625d00238 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 31, 2024, 7:07=E2=80=AFPM Justin Hibbits &= lt;jhibbits@freebsd.org> wro= te:
On Thu, 31 Oct 2024 15:33:39 -0= 700
Ravi Pokala <rpokala@freebsd.org> wrote:

> Hi Justin,
>
> So, this is like the 'crashkernel' thing Linux has, where it k= exec()s
> an alternate kernel when the main one panics?

If your description is accurate, then probably.=C2=A0 I don't know if t= he
crashkernel thing from Linux existed when this was started, and
actually hadn't even heard of it until now.

Yeah. There's three type= s of kernels: debug, crash, and replacement.=C2=A0
<= br>
>
> I haven't looked at the patch -- most of it will be way out of my<= br> > expertise -- but what, if anything, is done to make sure the on-disk > state of the target filesystem is okay, before the "rescue" = kernel
> starts writing to it?

Good question.=C2=A0 The rescue kernel embeds its own small rootfs it fscks=
the target fs before writing to it.

Yea. My loader.kboot loads the kernel an= d initrd too...

Warner


- Justin

>
> Thanks,
>
> Ravi (rpokala@)
>
> =EF=BB=BF-----Original Message-----
> From: <owner-freebsd-arch@FreeBSD.org
> <mailto:owner-freebsd-arch@FreeBSD.org>> on b= ehalf of Justin Hibbits
> <jhibbits@FreeBSD.org <mailto:jhibbits@FreeBSD.org>>= Date: Thursday,
> October 31, 2024 at 15:23 To: <freebsd-hackers@FreeBSD.org
> <mailto:freebsd-hackers@FreeBSD.org>>, <freebsd-arch@freebsd.org
> <mailto:freebsd-arch@freebsd.org>> Subject: Direct = dumped kernel cores
>
>
> Hi everyone,
>
>
> At Juniper we've been using a so-called 'rescue' kernel fo= r 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
> <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
>
>
>
>
>
>


--000000000000e9054b0625d00238--