Subject: Kernel stack being swept from under our feet?
To: None <port-sun3@NetBSD.ORG>
From: David Jones <dej@eecg.toronto.edu>
List: port-sun3
Date: 04/08/1995 20:47:18
In /sys/arch/sun3/sun3/process.s:
/* see if pmap_activate needs to be called; should remove this */
movl a0@(P_VMSPACE),a0 | vmspace = p->p_vmspace
#ifdef DIAGNOSTIC
tstl a0 | map == VM_MAP_NULL?
jeq Lbadsw | panic
#endif
lea a0@(VM_PMAP),a0 | pmap = &vmspace.vm_pmap
#if 0
tstl a0@(PM_STCHG) | pmap->st_changed?
jeq Lswnochg | no, skip
#endif
pea a1@ | push pcb (at p_addr)
pea a0@ | push pmap
jbsr _pmap_activate | pmap_activate(pmap, pcb)
addql #8,sp
Lswnochg:
lea tmpstk,sp | now goto a tmp stack for NMI
jbsr _load_u_area | load_u_area()
movl _curpcb,a1 | restore p_addr
The call to pmap_activate() results in the context being changed.
This effectively changes the VM mappings over to the new process.
Are kernel stacks stored in the same VA for each process? If so,
then between the call to pmap_activate and "lea tmpstk,sp" you
are not running on the same stack from which pmap_activate()
was called from!
In comparison, the Amiga pmap_activate() does not change the MMU
mappings. Rather, the stack pointer is switched to tmpstk,
then a small loop copies the new kernel stack in:
pea a1@ | push pcb (at p_addr)
pea a0@ | push pmap
jbsr _pmap_activate | pmap_activate(pmap, pcb)
addql #8,sp
movl _curpcb,a1 | restore p_addr
Lswnochg:
movl #PGSHIFT,d1
movl a1,d0
lsrl d1,d0 | convert p_addr to page number
lsll #2,d0 | and now to Systab offset
addl _Sysmap,d0 | add Systab base to get PTE addr
#ifdef notdef
movw #PSL_HIGHIPL,sr | go crit while changing PTEs
#endif
lea tmpstk,sp | now goto a tmp stack for NMI
movl d0,a0 | address of new context
movl _Umap,a2 | address of PTEs for kstack
moveq #UPAGES-1,d0 | sizeof kstack
Lres1:
movl a0@+,d1 | get PTE
andl #~PG_PROT,d1 | mask out old protection
orl #PG_RW+PG_V,d1 | ensure valid and writable
movl d1,a2@+ | load it up
dbf d0,Lres1 | til done
So why aren't we blown out of the water?
--
David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
email: dej@eecg.toronto.edu, finger for PGP public key
For a good time, telnet torfree.net and log in as `guest'.
Click me!