From nobody Fri Dec 19 18:42:31 2025 X-Original-To: dev-commits-src-main@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 4dXxGy46MGz6MDMM; Fri, 19 Dec 2025 18:42:34 +0000 (UTC) (envelope-from glebius@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dXxGy21rTz4FjT; Fri, 19 Dec 2025 18:42:34 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766169754; 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=e09q2+gpR/9kXHhDrLUP5cscrK2R5EhXzCuoecX/Nw4=; b=RPNVsVh9YfKpjxfONPp758Z1580jvnpAdfj2IYpmXYAoyORlcJ0LUBzgpid3i1ItK3DfB5 z1osSXOWL6Hn/GFUDcmGSb0ZGQ38uBDv2f+fuSNa5NKnVAFA81Si1p6BKkWsAWZO8zGFBR QGOSfLU8SgjCHNjFSZWf/D10dIydvHSI81+Ck7L4lufILQm6lSzPWaKzFnYCE75uO/N/Sm Kk2xuMOlV/uXgQV5PfbfTP1rVEPq/Oz/+A4R2IENehfrbY72FZmQdlaUWYBcJd4BhwaSHW h0qN8Hnvm4F+qpEBt4DnrKbF8dtnqM/apvmC7QiIZY9At65T6cdC4g6CMdIqtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1766169754; 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=e09q2+gpR/9kXHhDrLUP5cscrK2R5EhXzCuoecX/Nw4=; b=Js0t744gEoUFh0jBr3W22d8msbzHhqN6ZUAa7C04WnaDoo50Xp9cA9endQG8XqI1WncWBW X4n9EE+I79G3yT7TyHDQUpTuMJwkNx5Req61GQTjNNHo/vye9vwIN/zJP9jY4iVLj6fVcf cjiXa/5oAd94lKC7cdmTlejv4uGPsiLJKZti8iGcDTrEs2YKsnqk7ZG/aXR9i9LY9nFEnI vT4RuFARkixqEW37seMXWU8cKtSoVxjnI5DgfeKJy4wMDA05PPra3BZcSbh3/LrVHDKJTq XL6qAyU0RjjYWg+lCQ3BtXfLy6F556p3Iklb4N4aJ8vAepBRIcFjc+4lMwKYkA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1766169754; a=rsa-sha256; cv=none; b=HnCmRkZRKKq/jGGYyMinD7uYPLFL1UYl4+DWGlbc/dTbKdB7zN4ImbFfWke6h50ZID1U5P Bxl2PT1T9DPzYVAami1PpfUJG5HggLC7LmBBBcOwkEhmaZ1AGhX5h4rOlP4wulLABXHIP5 m/DE0PeXi7U81pkbInocSpi9ka+nX/hHyiHYPvpoGwTIVziOKqBL+VGfBxGBTVRgfYEgQN jt6TbMOKKQ2OzcKrcBna2EtjXzwVNaLnh4/+dkjG0RmPfX7lH2jo4rLDIlmt+9bkBHL3lx fZOtYngCZyWonTRt4Fs5pnPPZrj/7Lo1MoFUBLSe/qpGa543CwGKyRb3aGXSdA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dXxGx4VMWzs8n; Fri, 19 Dec 2025 18:42:33 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Fri, 19 Dec 2025 10:42:31 -0800 From: Gleb Smirnoff To: Kristof Provost Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 0d469d23715d - main - net: attach IPv4 and IPv6 stacks to an interface with EVENTHANDLER(9) Message-ID: References: <694452f3.32deb.4d0ab2a7@gitrepo.freebsd.org> <4A394DAA-1FCE-440A-8E92-88BD9B4EE087@FreeBSD.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A394DAA-1FCE-440A-8E92-88BD9B4EE087@FreeBSD.org> On Fri, Dec 19, 2025 at 12:10:09PM +0100, Kristof Provost wrote: K> I’m seeing panics on pfsync interface destruction now: K> K> panic: mld_change_state: bad ifp K> cpuid = 19 K> time = 1766142554 K> KDB: stack backtrace: K> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame K> 0xfffffe01843fd990 K> vpanic() at vpanic+0x136/frame 0xfffffe01843fdac0 K> panic() at panic+0x43/frame 0xfffffe01843fdb20 K> mld_change_state() at mld_change_state+0x6d0/frame 0xfffffe01843fdb90 K> in6_leavegroup_locked() at in6_leavegroup_locked+0xa9/frame K> 0xfffffe01843fdbf0 K> in6_leavegroup() at in6_leavegroup+0x32/frame 0xfffffe01843fdc10 K> pfsync_multicast_cleanup() at pfsync_multicast_cleanup+0x83/frame K> 0xfffffe01843fdc40 K> pfsync_clone_destroy() at pfsync_clone_destroy+0x260/frame K> 0xfffffe01843fdc90 K> ifc_simple_destroy_wrapper() at ifc_simple_destroy_wrapper+0x26/frame K> 0xfffffe01843fdca0 K> if_clone_destroyif_flags() at if_clone_destroyif_flags+0x69/frame K> 0xfffffe01843fdce0 K> if_clone_detach() at if_clone_detach+0xe6/frame 0xfffffe01843fdd10 K> vnet_pfsync_uninit() at vnet_pfsync_uninit+0xf0/frame 0xfffffe01843fdd30 K> vnet_destroy() at vnet_destroy+0x154/frame 0xfffffe01843fdd60 K> prison_deref() at prison_deref+0xaf5/frame 0xfffffe01843fddd0 K> sys_jail_remove() at sys_jail_remove+0x15c/frame 0xfffffe01843fde00 K> amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe01843fdf30 K> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe01843fdf30 K> --- syscall (508, FreeBSD ELF64, jail_remove), rip = 0x2d8234c9e31a, rsp = K> 0x2d823179b928, rbp = 0x2d823179b9b0 --- K> KDB: enter: panic K> K> The pfsync:basic_ipv6 seems to trigger this reliably. This actually surfaced an interesting problem, and pfsync being an interface isn't a culprit here :) Neither my changes are. The problem is that IPv6 multicast layer in in6_getmulti() will call into interface multicast layer with if_addmulti() to allocate struct ifmultiaddr. This new born ifmultiaddr will have refcount of 1, but it will be referenced both by the struct in6_multi and the interface linked list. It should have refcount of 2. For all normal cases the in6_multi structs are also somehow associated with the interface they were allocated for and at teardown sequence they will go away all together, so this refcounting bug never triggers. But with pfsync calling in6_joingroup() on some ifnet from its own pfsync's context we come into a situation when the struct in6_multi is external to the ifnet it is associated with. If this ifnet is detached before pfsync context is destroyed, then our in6_multi will point at a detached ifnet that is hanging on the last reference (all methods point to if_dead) and this in6_multi will also point at freed ifmultiaddr. I'm looking at either a proper fix or at hiding it back under carper as it was before. -- Gleb Smirnoff