From nobody Thu Oct 31 22:32: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 4Xff005yW6z5cWKL for ; Thu, 31 Oct 2024 22:33:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 4Xff0047y1z3xpk for ; Thu, 31 Oct 2024 22:33:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-71e8235f0b6so1206315b3a.3 for ; Thu, 31 Oct 2024 15:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1730413983; x=1731018783; 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=H26D70ZxWtgAZfgUQiYcsEce7YGQBqm3RU3p92sQdug=; b=rxDBWvNVH+YJYuQGjD7ZswTBjmMOKAhEmj38V16/lbZiE60iaE7a8dz2OvZDrCVJXo U5SoiwIsQbmEONj6pv+EadY5N7nYKDNki5xKQuQG8bov+kUN7a2tzffudvO8RANnZJAA US950XQNz0+7v05tW0OGY5yQT7h0T6CNRrNqxNS9weHFx9QsiLhchl6MPjqUupI9uoPL DvkauR7dIucAt3XnhGBsR9zmyJoPKR+KEETpyTSBjZeZ2HZLP8Ym6rdkig5QiZrUcW/t ZN5W6roRI6CNaoOrA59mcgpzlmcxH4NMhRFM3r/FH3PZVZDVWKfibowvTPXQiwX50lo5 y7EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730413983; x=1731018783; 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=H26D70ZxWtgAZfgUQiYcsEce7YGQBqm3RU3p92sQdug=; b=lNLGUcFNLFxDpC4N/zh9j6JHnN8x9bNzaVjAa1uzgDM8Vsv6Jmwb/5xwWrlXugV1kL +9BZ0c16lku2FWCLSBnlxeZOSrLKVbgjeG/sXy5wIJHkDrDmnuKBrC3pA6kKnnABHdCe sJriJ3EDAVtdj98d85tpEVHm5tcMuJuvDOZ9s9zERQRXPdb7GhP8j/9PdBu5jOEHTMvH 5Iw/fcmhdAegEbcqDHvkhU3TlsdnJXFwW9P1wpNyJNdR6KN5qIqNiBuInmRt8jd9mxGm H236fi6saVLBWQ//yXO5QwkNWdbjoGC9eaRNrUNcsbv3kJyC+s+4go+9zc05mY4dXWqK Hhxg== X-Gm-Message-State: AOJu0YxjsMSszBhUTbwD40n1CgvL9bSUmU02ABGy+UGucaIM0y1VCuNP R8Lv1omv7pIJUahWyJSkCv2ByHfhGxcQf3it7pR91TqXx8JW8NDZsS1gQrVuFZ9WIDwdZ8XurPd D8Qzr5ggBCP7zQtS6y4/JnJhDs219mcgN1sLqbzPJnRClKVBrh9Y= X-Google-Smtp-Source: AGHT+IEiyAAlUCE0W4knf0cQnC4Y/2pjlVTyQ5R2P6HaLmxe3nUJVVmu1r1ODyxm6kaYZHH5Cnjb0ZVIT2VsfpANGGg= X-Received: by 2002:a17:90b:3c46:b0:2e2:d239:84be with SMTP id 98e67ed59e1d1-2e93c159030mr6189766a91.5.1730413982795; Thu, 31 Oct 2024 15:33:02 -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> In-Reply-To: <20241031182354.14fa48aa@ralga.knownspace> From: Warner Losh Date: Thu, 31 Oct 2024 16:32:51 -0600 Message-ID: Subject: Re: Direct dumped kernel cores To: Justin Hibbits Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c2670d0625cd66ec" 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: 4Xff0047y1z3xpk X-Spamd-Bar: ---- --000000000000c2670d0625cd66ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 31, 2024 at 4:24=E2=80=AFPM Justin Hibbits wrote: > 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`. > 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 anothe= r drive to the system that was panicking and dump to that). 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. Warner > There are many more details in the review summary. > > We'd love to get feedback from anyone interested. > > Thanks, > Justin Hibbits > > --000000000000c2670d0625cd66ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 31, 2024 at 4:24=E2=80=AF= PM Justin Hibbits <jhibbits@free= bsd.org> wrote:
Hi everyone,

At Juniper we've been using a so-called 'rescue' kernel for dum= ping
vmcores directly to the filesystem after a panic.=C2=A0 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,
=C2=A0 the other to build the main kernel, which embeds the rescue kernel =C2=A0 inside its image.=C2=A0 This might need some further work.
* Thus far it's been implemented for amd64 and arm64, once proven out,<= br> =C2=A0 other architectures (powerpc64/le, riscv64) can follow suit.
* Kernel environment bits to pass down to the rescue kernel are
=C2=A0 prefixed `debug.rescue.`, for instance
=C2=A0 `debug.rescue.vfs.root.mountfrom`.

First off, this is kinda cool. I've wanted=C2=A0this occasionally wh= en my swap
partition=C2=A0is too small (though in my case, it was= easy enough to add another
drive to the system that was panickin= g and dump to that).

I do have a question: I'm= curious why you didn't follow the Linux lead of having
a kex= ec_load(2) system call to load the 'rescue kernel' to make this mor= e generic.
That would make the leap to having full kexec support = (eg reboot(CMD_KEXEC)
a lot easier to implement.

Warner
=C2=A0
There are many more details in the review summary.

We'd love to get feedback from anyone interested.

Thanks,
Justin Hibbits

--000000000000c2670d0625cd66ec--