Peter Wemm wrote:
> Bruce Evans wrote:
> > >calcru() access p_stats, which is in upages. Therefore, as I understand,
> > >it should not be called on a swapped out process. Neither calcru() nor
> >
> > Does anyone object to moving everything except the stack from the upages
> > to the proc table?
This would certainly make my sleep better. However, IMO the real
problem here is the hackish way the VM maintain upages. It is not
so hard to make such incorrect accesses to u-area detected better.
I used this:
--- vm_glue.c Thu May 20 00:24:18 1999
+++ vm_glue.c Thu May 20 00:27:33 1999
@@ -317,6 +317,9 @@ faultin(p)
setrunqueue(p);
p->p_flag |= P_INMEM;
+ p->p_stats = &p->p_addr->u_stats;
+ if (p->p_sigacts == NULL)
+ p->p_sigacts = &p->p_addr->u_sigacts;
/* undo the effect of setting SLOCK above */
--p->p_lock;
@@ -516,6 +519,9 @@ swapout(p)
(void) splhigh();
p->p_flag &= ~P_INMEM;
p->p_flag |= P_SWAPPING;
+ p->p_stats = NULL;
+ if (p->p_sigacts == &p->p_addr->u_sigacts)
+ p->p_sigacts = NULL;
if (p->p_stat == SRUN)
remrq(p);
(void) spl0();
Probably better idea would be pass MAP_NOFAULT in a non-currently-existent
argument to kmem_alloc_pageable() in pmap_new_proc().
> Well, we have three things that are about the same size:
> struct pcb u_pcb; 240 bytes
> struct sigacts u_sigacts; 292 bytes
> struct pstats u_stats; 248 bytes
>
> On the other hand: sizeof (struct proc) = 328 bytes.
>
> the pcb contains a heap of space for the FP state. It accounts for 176 of
> the 240 bytes, leaving 64-odd bytes left for the pcb proper. The ldt
> pointers need to move to proc scope for rfork()/clone(), and gc'ing a few
> things that can get it as low as 40 - 48 bytes. pcb_savefpu has padding in
> case a FPU emulator is used and is actually smaller than 176 bytes, and
> could be changed depending on whether it's a real or emulated fpu.
I guess, this is bit different on alpha ;-).
>
> IMHO, I'd move them to reference counted malloc'ed structs since sigacts
> needs to be shared for clone/rforked processes.
I think sigacts is already sometimes shared, and not stored in u-area
in these cases.
> I think there is also
> benefit to having the sigacts at least malloced, one day we should be able
> to extend the signals beyond the existing 32 set, at least for the 32
> extra RT signals.
Isn't this an argument for keep them in upages? When the struct is
larger, you want to swap it out stronger?
> I personally would love to see this come out of the upages, it makes
> tracking through a stack overflow even harder. We could put an unmapped
> red-line page below the bottom stack page to ensure we get a double fault
> on an overflow instead of mystery corruptions etc.
Why not move 'struct user' on top of the upages, above the kernel stack?
Sayed all that, I don't actually suggest to keep struct user. I almost
hate it.
Dima
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
