🚀 go-pugleaf

Recently David Buxbaum wrote about a V7 scheduling bug:

>I recently found an interesting bug in the Version 7 shared text code
>which, under the right circumstances, causes deadlock in the kernel.

To summarize, he was worried that a process exiting and writing out a
shared text segment had that text segment locked but could then be
swapped out in the middle of writing out that text segment.  When the
scheduler wants to schedule one of the other processes using the segment,
he hangs because he needs to lock that segment temporarily.

The scheduler code is:

>		if (rp->p_textp && rp->p_textp->x_flag&XLOCK)  
>			continue;

I cannot find a problem.  The flaws in the argument seem to me to be:

First, when you are busy writing out a shared text segment (with a call
to swap()) you are considered to have I/O in progress, and therefore your
process is *locked in core*, preventing you from being swapped!  You can be
descheduled, but you cannot be swapped out.

Second, the above code should prevent the other processes from being
scheduled, because their proc table entries still have a valid p_textp
that points to an XLOCK'ed text segment.

What have I missed?  We have never observed any problems like this.  Maybe
he has done some special work to his device drivers that lost the process
lock during I/O.

-- 
					Joe Guthridge
					..!akgua!lanierrnd!jwg