Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site lanierrnd.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!lanierrnd!jwg From: jwg@lanierrnd.UUCP (Joe Guthridge) Newsgroups: net.bugs,net.bugs.v7,net.unix-wizards Subject: Re: v7 shared text bug & fix. Message-ID: <34@lanierrnd.UUCP> Date: Fri, 30-Nov-84 10:22:29 EST Article-I.D.: lanierrn.34 Posted: Fri Nov 30 10:22:29 1984 Date-Received: Sat, 1-Dec-84 20:27:21 EST References: <> Reply-To: jwg@lanierrnd.UUCP (Joe Guthridge) Distribution: net Organization: Lanier Business Products, Inc., Atlanta, Georgia Lines: 34 Xref: lanierrnd net.bugs:14 net.bugs.v7:2 net.unix-wizards:305 Summary: 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