Questions regarding 4.[23]BSD context switching.

[Allen Brumm]

I have two questions/concerns regarding the low level context switch
routine (swtch()) in 4.[23]BSD systems.

When a process exits, it frees its pages of u-area and kernel stack
by calling vrelu().  Either before this call, or within vrelu() itself
(depending on whether you are using 4.2 or 4.3) the IPL is raised to
block out network interrupts (splimp()).  The intent of raising the
IPL is to not allow memory allocation in the network code, in particular,
to avoid a page of mbufs being allocated in a network interrupt routine.

The problem that I see is that after exit calls vrelu() and finishes the
rest of its work, it then calls swtch().  Swtch() idles at a low IPL in
the context of the exit'ing process.  While swtch() is idling at a low
IPL, what is to prevent a network interrupt from coming in and allocating
the page which corresponded to the exit'ing processes u-area?

When swtch() finds a process ready to run and emerges from the idle loop
it still expects the exit'ing processes u-area page to belong to the
exit'ing process.  It does a svpctx instruction which writes the pcb at
the beginning of the u-area, and it saves the CMAP2 entry in the u-area.
If this page had been re-allocated by a network interrupt routine, a
possibility exists of destroying a page of mbufs (or at least part of it).

This is probably an unlikely event since the u-area pages and kernel stack
freed by the exit'ing process are put at the end of the free list.  But
it is still possible as far as I can tell.

So my question is:  Is there something that prevents the above scenario
from occurring which I am failing to notice?  If so, please let me know.


My second question is something that has bothered me for quit a while
(not very much though) and has to do with the assignment of sleep
priorities in 4.[23]BSD.

Since the sleep priorities range from 0-127 and are divided by 4 to
fit in the range of 0-31.  Presumably for the purpose of the using the
VAX 'ffs' instruction on the variable whichqs.  Sleep priorities which
fall into the same runq position are treated equally (after the division).
It would seem that if you truly want an event completion/notification to
have a higher priority over some other event completion/notification you
must make sure that the sleep priority used will divide to a higher (lower)
runq position relative to the other event.  This is fine.  What bothers me
is the assignment of TTIPRI (28), and TTOPRI (29).  The intent being to
treat input notification with a higher priority than output completion
(receive over transmit) then the two (or more) processes should be placed
on different runq positions.  Both 28 and 29 divide by 4 to equal 7.  It
seems as though 27 and 28 would be better choices.   Any comment?


Thanks

Allen Brumm
uunet!ccicpg!capone!allen