Re: port-vax/57839

["Kalvis Duckmanton via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-vax/57839; it has been noted by GNATS.

From: Kalvis Duckmanton <kalvisd%gmail.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-vax/57839
Date: Tue, 10 Nov 2026 23:22:51 +1100

 To recap:
 The ATF test /usr/tests/lib/libc/sys/t_lwp_create:lwp_create_bad_lid_ptr 
 invokes sys__lwp_create() with a bogus lwpid_t *.
 
 In sys__lwp_create(), the creation of the new LWP by do_lwp_create() 
 succeeds, but the subsequent copyout() of the LWP ID fails due to the 
 bogus pointer and the newly created LWP, having never run, is then 
 destroyed by lwp_exit().
 
 do_lwp_create() ends up calling vax/vm_machdep.c:cpu_lwp_fork(), which 
 in turn calls pmap_activate().  pmap_activate() does a few things -- it 
 stores values for the P0 and P1 base and length registers in the new 
 LWP's PCB and links that PCB into the list of PCBs using the pmap.  
 While pmap_activate() can also load the CPU's P0 and P1 registers, it 
 doesn't at this time because the new LWP is not the one currently active.
 
 Later, because the LWP never ran, the matching pmap_deactivate() is 
 never called and the reference in the pmap to the PCB remains, leading 
 to a panic when the pmap is destroyed.
 
 After investigation, the consensus is that the call to pmap_activate() 
 in cpu_lwp_fork() is not needed; pmap_activate() (and the matching 
 pmap_deactivate()) will be called later as the LWP is scheduled.
 
 However, one of the side-effects of pmap_activate() is still required -- 
 the values for the P0 and P1 registers in the new LWP's PCB need to be 
 initialised, and in particular the initial AST level needs to be set to 
 AST_PCB (no ASTs pending)
 
 cheers
 kalvis