Re: Set PSTATE.PRIV for user process

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

On Thu, 22 Oct 2026 20:32:08 +0000 (UTC)
Palle Lyckegaard <palle%netbsd.org@localhost> wrote:

> On Thu, 22 Oct 2026, Sad Clouds wrote:
> 
> > On Thu, 22 Oct 2026 18:40:58 +0000 (UTC)
> > Palle Lyckegaard <palle%netbsd.org@localhost> wrote:
> >
> > How do you know the issue happens on a context switch? And how can I
> > verify that when calling a function in a user process this causes a
> > context switch before this function returns?
> >
> 
> The issue I am tracking down happends when a syscall is issued.
> When the control is handed back to user-land the registers contains some 
> garbage value from time to time.
> 

I'm observing something different. Register corruption happens around a
function call when it executes save/restore instructions. There appear
to be spill/fill traps taken during this moment. I know this because I
set the register save area at %sp+bias to unique test values and then
observe what happens to them.

src/external/bsd/jemalloc/dist/src/extent.c

ecache_alloc_grow()
{
	...

	v9reg_save(&reg_info[0]);

	edata = extent_alloc_wrapper(tsdn, pac, ehooks, new_addr,
		size, alignment, zero, &commit,
		/* growing_retained */ false);

	v9reg_save(&reg_info[1]);

	// Check for %fp registers corruption and crash with illegal instruction
	if (reg_info[0].in[6] != reg_info[1].in[6]) { __asm__ __volatile__("sir" ::: "memory"); }
        
	...
}

So:

1) Caller's %l0-%l5 registers are written correctly to %sp+bias save
area.
2) Caller's %l6 and %l7 registers are NOT written to %sp+bias save area.
3) Caller's %i0 register seems to be written correctly to %sp+bias area.
4) Caller's %i1-%i7 registers are NOT written to %sp+bias save area.

When callee returns and executes restore (resulting in a fill trap):

%l0-%l5 registers are restored with correct values, but %l6 and %l7 are
restored with the same random values at %sp+bias save area that were
there before the spill trap.

%i0 register is restored correctly.

%i1 register contains the same value that is currently in %o1.

%i2-%i7 registers are restored with the same random values at %sp+bias
save area that were there before the spill trap.

However %i5 register save area at %sp+bias+104 contains the same value
that was in %i6 (%fp) before the spill trap. This seems to be quite a
unique behavior.

Something is really whacky going on here. It feels like during
save/restore another trap occurs (text or data fault?), causing partial
register save/restore and messing up their values.

The table below summarises my test and is best views maximised on a wide
screen, to avoid text wrapping.

Register snapshots were taken with custom assembly code written as a
leaf function to avoid shifting register window. The stack test values
were set starting at %sp+bias to unique 0x555555555555555N or
0x666666666666666N values, where N identifies register index. 


Register   Register value      Stack value             Register value       Stack value
---------  --------------------------------------     --------------------------------------
                    Before save/restore                         After save/restore
           --------------------------------------     --------------------------------------
%l0        0x66666665          0x5555555555555550     0x66666665          0x0000000066666665    OK
%l1        0x66666663          0x5555555555555551     0x66666663          0x0000000066666663    OK
%l2        0x40828eb0          0x5555555555555552     0x40828eb0          0x0000000040828eb0    OK
%l3        0x66666662          0x5555555555555553     0x66666662          0x0000000066666662    OK
%l4        0x0                 0x5555555555555554     0x0                 0x0000000000000000    OK
%l5        0x6666666666666663  0x5555555555555555     0x6666666666666663  0x6666666666666663    OK
%l6        0xffffffffffffc0e5  0x5555555555555556     0x5555555555555556  0x5555555555555556    NO Test stack value restored.
%l7        0x40810cc8          0x5555555555555557     0x5555555555555557  0x5555555555555557    NO Test stack value restored.

%i0        0x0                 0x6666666666666660     0x40a17e80          0x0000000040a17e80    ?  Could be OK as %i0 was modified.
%i1        0x40a03a00          0x6666666666666661     0x6666666666666661  0x0000000000001400    NO Test stack value restored. Stack value modified, could be %o1 value.
%i2        0x40a00100          0x6666666666666662     0x6666666666666662  0x6666666666666662    NO Test stack value restored.
%i3        0x40216050          0x6666666666666663     0x6666666666666663  0x6666666666666663    NO Test stack value restored.
%i4        0x1438              0x6666666666666664     0x6666666666666664  0x6666666666666664    NO Test stack value restored.
%i5        0x2000              0x6666666666666665     0x6666666666666665  0xffffffffffffb911    NO Test stack value restored. Stack value modified, looks like %fp value.
%i6 (%fp)  0xffffffffffffb911  0x6666666666666666     0x6666666666666666  0x6666666666666666    NO Test stack value restored.
%i7        0x4057c7f8          0x6666666666666667     0x6666666666666667  0x6666666666666667    NO Test stack value restored.

%o0        0x40828eb0                                 0x40829028        
%o1        0x6666666666666662                         0x1400            
%o2        0x66666661                                 0x1               
%o3        0x66666667                                 0x0               
%o4        0x66666664                                 0x2000            
%o5        0x6666666666666666                         0xffffdfff00000000
%o6 (%sp)  0xffffffffffffb7d1                         0xffffffffffffb7d1
%o7        0x40589e14                                 0x40589e48        

%g0        0x0                                        0x0               
%g1        0x730000                                   0x730000          
%g2        0x66666660                                 0x0               
%g3        0x1400                                     0x0               
%g4        0x6666666666666660                         0x0               
%g5        0x66666666                                 0x40588064        
%g6        0x206e69730a                               0x206e69730a      
%g7        0x40216ac0                                 0x40216ac0