Re: Tracing NetBSD sun4v issues

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Fri, 16 Oct 2026 09:36:07 +0100
Sad Clouds <cryintothebluesky%gmail.com@localhost> wrote:

> So it is possible that the above text and data access fault handlers
> are causing corruption somewhere. I also find it suspicious that when
> SEGV occurs there is a data access fault:
> 
> [  65.2929154] 110: data_access_fault(0x154697ed0, 31, 0x40589b50, 0xffffc011, ffffc000, 1) nsaved=0
> 
> where:
> 0x154697ed0  trap frame address
> 31           trap type
> 0x40589b50   program counter
> 0xffffc011   faulting virtual address
> ffffc000     synchronous fault virtual address
> 1            synchronous fault status register

If we assume the faulting virtual address could correspond to the
truncated stack address, then data_access_fault() in called from
sun4v_datatrap:

sun4v_datatrap:
	GET_MMFSA %g3				! MMU Fault status area
	add	%g3, 0x48, %g1
	LDPTRA	[%g1] ASI_PHYS_CACHED, %g1	! Data fault address
	add	%g3, 0x50, %g2
	LDPTRA	[%g2] ASI_PHYS_CACHED, %g2	! Data fault context

	TRAP_SETUP(-CC64FSZ-TF_SIZE)
	or	%g1, %g2, %o3
	mov	%g1, %o4
...

Argument 4 is passed in %o3 register, which is set to (%g1|%g2) and the
upper bits are zero when both of %g1 and %g3 registers bits are also
zero. This means LDPTRA macro (ldxa instruction) loaded those values.
So is it reading from the wrong or stale MMU Fault Status Area? Is
there a race condition when the fault status area can be updated with a
different fault while we are trying to read it?