From nobody Wed May 27 16:15:59 2026 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 4gQZVR1pScz6fH9w for ; Wed, 27 May 2026 16:15:59 +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 "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gQZVR168dz3kkd for ; Wed, 27 May 2026 16:15:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1779898559; 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; bh=3/einUAHRO022puIPES/SnWmn4OJHUKGimEU+JQnrnQ=; b=fwZSQ0JxKXxh0WS55ZXqW1JNObLTWSwg4KXnEdG2ELZ6q1Z1WwT4LMyqlFmpPlw6Vb3ONu UzFWZoAj77XMTBTbW2cH4iFXMICFqXcHlwm/2ko8dB6CAcjXUd+9IpLYO9MwFw0Sa2Fq3E HnivjGIXWXUIIi9f4kn2vpCXm237CtxKYN0JQmyENgWmcWFII/GdJ5Ss7QVohcAGxCwlNI ptm9UES+kniZPVmylk+iOld3Jbrcej1tzv03k1DZQXUsvRPCe3r3AFYg5TgJ6UWjwITwLK XAGjedc+SfsvN1oxSKDTN0Cv+9FOpewUw+/x7NRfp9xpX0oRqyTzHlV7FAqr3Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1779898559; a=rsa-sha256; cv=none; b=ieTBeY3OcNdf+ylsjWDUCVmO7MwpowcJdbQ6a3VbMBvHEUyL85lMr90k8RRPP375LGJNEL Eardzsx7nN4enpVfiOKvq3FrkqaQwbzrQEHhCahS9Smcl+TbCptzKtwZ0f9ioaDoOrtsvO iyRmEuHziSx7yIpoUqEls7mJechPWA+yK72FF7A3g8Xpy9+efDozWixY+4+lCTzSanq9GX lU7EzCYz7SH+TUV3iZPGL9URJJlGB4rsXL3p/2UiRkMKWa88SZk9kHK9HzfOWZU57fGd6b sqaiakqfOO9qMYqZVEQxQOvRD0AxI6aIbu5WuS/MMVB6p3i53/e4p3O0xT1ybg== 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=1779898559; 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; bh=3/einUAHRO022puIPES/SnWmn4OJHUKGimEU+JQnrnQ=; b=x6nmnItxa7ETbnHw6ERVi/jyeypvyFjW0SGPmDPv3qhF9F/eSYzz++F76DUsRBGLPy0DvD 1cpb6dasUxZPXpm0i6EZpUOa7elWwhfUdKbQhbgfpV7cox8n0UwBdCP5WCs46ouknoGmjO E/OEBayJGg1wNFZVkfFB65sdXx204TjTzyf2+bC+IqT9Oknn+wqqGy4q4HuvanhoulkvNy d7JjqVzh/DwJfG2eGs/+RI0B7Bv/KVdcMjICoI1QCLO11cd85BMglFHPHwKvWH5ojRFT3z pzh39OJBoz43trEoy6mM9202g+mq0fztTnFJU4pweGF3B3c6XGCcQytXaLXPtw== 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 4gQZVQ75MWz15SK for ; Wed, 27 May 2026 16:15:58 +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 64RGFwVA048250 for ; Wed, 27 May 2026 16:15:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 64RGFwRt048249 for bugs@FreeBSD.org; Wed, 27 May 2026 16:15:58 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 295649] Fix bhnd_pmu_core_attach() cleanup on PMU attach failure Date: Wed, 27 May 2026 16:15:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.4-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lihaoxiang@isrc.iscas.ac.cn X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D295649 Bug ID: 295649 Summary: Fix bhnd_pmu_core_attach() cleanup on PMU attach failure Product: Base System Version: 14.4-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: lihaoxiang@isrc.iscas.ac.cn Created attachment 271259 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D271259&action= =3Dedit possible patch bhnd_pmu_core_attach() leaks the per-core PMU state allocated by bhnd_alloc_pmu() when the subsequent bhnd_pmu_attach() call fails. I tested this on FreeBSD 14.4-RELEASE amd64, but the affected code path does not app= ear to be specific to this version. In bhnd_pmu_core_attach(), the register resource is allocated first, then bhnd_alloc_pmu() is called. If bhnd_pmu_attach() later fails, the code rele= ases the register resource but does not call bhnd_release_pmu(). This leaves the PMU allocation owned by the bhnd bus child active. The API contract in bhnd.h says the register resource must remain allocated until a= fter bhnd_release_pmu(), so the expected unwind order is to call bhnd_release_pm= u() before releasing the register resource. I tested this on FreeBSD 14.4-RELEASE amd64 in QEMU. I do not have real bhnd/bcma/siba hardware, and the VM has no Broadcom PCI device, so I used a kernel-side fault-injection harness. The harness creates a synthetic bhnd b= us and bhnd_pmu child, then forces bhnd_pmu_attach() to fail by returning ENOD= EV from the parent bus read_board_info method. This exercises the real bhnd_pmu_core_attach() error path. To verify the leak, the harness' BHND_BUS_ALLOC_PMU method allocates from a dedicated malloc type, bhndpmuflt, and leaves the allocation active unless BHND_BUS_RELEASE_PMU is called. After the forced attach failure, vmstat -m showed: Type Use Memory Req Size(s) bhndpmuflt 1 16 1 16 This shows that bhnd_alloc_pmu() succeeded, but the failure path did not ca= ll bhnd_release_pmu(). Thus, cleanup is necessary on the bhnd_pmu_attach() failure path. There is = also a related cleanup issue by inspection in bhnd_pmu_core_detach(). I didn't t= est it, but bhnd_release_pmu() is nessasry from my view. --=20 You are receiving this mail because: You are the assignee for the bug.=