From nobody Mon Oct 2 14:10:36 2023 X-Original-To: bugs@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 4RzjXY4n0Pz4w76C for ; Mon, 2 Oct 2023 14:10:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RzjXY3l4xz3b0r for ; Mon, 2 Oct 2023 14:10:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1696255837; a=rsa-sha256; cv=none; b=PeyNEBSEuSkXTrCoRQmpPIjwHN2Leg6YzbIeOhWkeT2CjrCV6bL2bAJxDhScxEW1V8yuia DwoPJrHOXwbYrN9J16chlO067WP0X3z/29S+iesLKnqQnG3OMnhxa0cVB8P8GrXzvMwWME nx9z+GX7bJXjs4KCVKWCeZsOk2vvbCpOfkfJtavSFaPLtXj3N2gmUEyXUHUwMP8wqpUtO7 iC7ke3/BhPkVzc0g2AJnNnYTEsFaud544M//MuQLc6Hlt2vqAPeV/BsiL75MOyN6nJP/nK llVwjDRFK//fvbzmFE+vAbiBaLhdESYRcwaE0VEK4RjMh/IxLw1cpqaVQNs1hQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1696255837; 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=MJTSG/Twobl1tig4eTMlENdj3qZ8Kntt7q2rAtLMOKc=; b=Lx02xeaJqS+A50hRDQxLozxwsn83b0R4/fVgX6cChPo/MHaxeN+8dbbS8MCVoyyxqS9Bh5 cYjWfs4g6cmonWIPw1wD+pOcsmh7eAdLNG2l+k+dT3xUt31N+FNjQDgUgMhK9L8e9cEQRk JsCb1UycWuPxebKW1nitGq0oCitM3h4xH00XI88+7tb/XRJlqqWViRyfxIUXdnWHc6c9Qw yhWQTBT1mvvQ6BgW515oD9KmcUvNyeRy4tghg1iCj5vvDrarCw3sKmC7APkueNPvoaAlXv BphWuC8WfKH8BC1aez/r/7aOU2B3mGufoLfAaSEtWDzf8iLO9hDzFxcoY6q2fw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4RzjXY2rM1zxK for ; Mon, 2 Oct 2023 14:10:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 392EAb0o046680 for ; Mon, 2 Oct 2023 14:10:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 392EAbMb046679 for bugs@FreeBSD.org; Mon, 2 Oct 2023 14:10:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 273715] dumpon: Kernel panic on boot when enabling dumpon over IP Date: Mon, 02 Oct 2023 14:10:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: grembo@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273715 --- Comment #10 from Michael Gmelin --- (In reply to Mark Johnston from comment #9) > How did you come to that conclusion? By the art of baseless speculation. I compared the actual 13.1 and 13.2 boot sequences, and on both the interfa= ces are renamed after dumpon is called. So forget that. I spent the time to actually read your patch the previous change that lead = to it, so this all makes sense now (Captain Obvious reiterating): https://cgit.freebsd.org/src/commit/sys/netinet/netdump/netdump_client.c?id= =3D38a36057ae56c8023878f3c3c2185bafc2896964 introduced a check if the device supports debugnet. This check couldn't deal with non-existing interfaces, which is the bug you fixed. Before the check was introduced, setting the renamed interface name was fin= e, since at the point the panic I tested with happened - which is after device renaming - it just worked(tm). If there was a panic between dumpon and devi= ce renaming, netdump would have failed of course (but that's a rare thing to happen). Now with the check in place, it first crashed (due to the bug reported) and= now - with the fix - will not catch on, as an interfaces named "untrusted" cann= ot be found. I see various options how to resolve this: 1. Always allow using the physical device name (so it would somehow poke ar= ound and find it) 2. Add a flag to dumpon (e.g., `-f` for force) to skip the device exists/de= vice supports debugnet check 3. Allow specifying multiple devices netdump_client to try when dumping 4. Determine based on the device name if it can exist early (feels wonky) For my setup, 2. would be sufficient and easy to apply (as this means that = all I have to do to adapting my base rc.conf for a new host is modify the ifconfig__name line in rc.conf). It would also be quite easy to implement I assume (DIOCGKERNELDUMP would need to be extended though - unle= ss some encoding in one of the existing parameters is done, like "dumpon -s 192.168.1.1 -s 192.168.1.2 untrusted:nocheck"). Alternatively this could ma= ybe be handled using a sysctl(?). --=20 You are receiving this mail because: You are the assignee for the bug.=