Re: Need help from a VAX abi expert (was: Reproducable kernel crash)

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, Jan 11, 2025 at 02:35:20PM +0100, Anders Magnusson wrote:
> pmap_activate() ensures that the page tables for the new lwp are correctly
> setup (as is written in the comment above).
> Since an lwp on vax runs as its own (vax) process it must have everything
> setup in its PCB as a new process and must be handled as a new process, so
> cpu_lwp_fork() must initialize the page tables as well.
> 
> The panic given in the ticket is that it gets an AST in kernel mode, which
> is unwanted.   ASTs are delivered to userspace to force a context switch.
> This error is typical that the PCB is not initialized correctly.

I figured that much.

> So, I do not think it has anything to do with the CALLS frame.

OK, that was probably me jumping to conclusions.

> Followup question is: If this is not the correct way of working (which means
> I misunderstood something sometime ? ), how should it work?

What you describe is correct and all fine, this is probably something that
didn't matter much some years ago but now is causing confusion (at least
confusing me).

I see pmap_activate(l) does basically two things:

 - fiddle with the PCB of l (this is the part needed in the call that I
   want to remove)

 - if l == curlwp also switch the CPU to this pmap

I think (but I am not sure) in modern semantics pmap_activate() should only
do the l == curlwp part (and probably uncoditionally), and the first part
should be moved elsewhere (that could be inline into the call I was trying
to remove) and only be done once at lwp creation time.

Side note:
what I don't undstand is why VAX needs a list of PCBs in its struct pmap.
Doesn't this always map 1:1 to the list pcbs of all lwp's in the process?
This list handling seems to be different to all other pmaps I have seen.

Martin