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.=