GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 6058dTVv074272 for freebsd-arm@FreeBSD.org; Mon, 5 Jan 2026 08:39:29 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: freebsd-arm@FreeBSD.org Subject: [Bug 292195] arm64: panic on coredump with sve instructions Date: Mon, 05 Jan 2026 08:39:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 16.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: william.a@carrel.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@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: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D292195 Bug ID: 292195 Summary: arm64: panic on coredump with sve instructions Product: Base System Version: 16.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: william.a@carrel.org Created attachment 266838 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D266838&action= =3Dedit vfp.c.patch When trying to reproduce bug 292177 on 16-CURRENT I unexpectedly encountere= d a kernel panic. It looks like the panic was unique to coredumping in SVE code. The coredump logic calls get_arm64_sve twice: once to get the note size, and once to get the data. The note size calculation depended on the volatile PCB_FP_SVEVALID flag. If this flag was cleared between the two calls (e.g.,= due to a context switch clearing the flag to comply with the ABI), the second c= all would expect a smaller buffer size than the first, triggering the KASSERT p= anic ("invalid size"). Fix this by: 1. Using pcb->pcb_svesaved !=3D NULL (a stable indicator of SVE usage) to determine the note size. 2. Calling vfp_to_sve_sync() if SVE is not currently valid but SVE state is saved, ensuring the SVE buffer in the core dump contains the most up-to-date register values. --=20 You are receiving this mail because: You are the assignee for the bug.=