Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ogicse!usenet!prism!gatesl
From: gatesl@prism.cs.orst.edu (Lee Gates)
Newsgroups: comp.unix.internals
Subject: Re: Help with 4.3 mod to kill uninteruptable procs.
Message-ID: <1991Feb23.075544.13388@lynx.CS.ORST.EDU>
Date: 23 Feb 91 07:55:44 GMT
References: <1991Feb19.001941.29928@lynx.CS.ORST.EDU> <1991Feb21.152845.29019@cbnews.att.com> <5558@awdprime.UUCP> <1991Feb23.025958.9914@cbnews.att.com>
Sender: @lynx.CS.ORST.EDU
Reply-To: gatesl@prism.CS.ORST.EDU (Lee Gates)
Organization: Oregon State Univ. -- Computer Science
Lines: 37
Nntp-Posting-Host: prism.cs.orst.edu

In article <1991Feb23.025958.9914@cbnews.att.com> rock@cbnews.att.com (Y. Rock Lee) writes:
>
>This was what I had in mind (which was wrong after I double checked it):
>
>	A signal puts this sleeping process back into the run queue (its 
>	priority has been set to higher than PZERO). sleep doesn't return;
>	it does a longjmp back to syscall. Before the system call returns,
>	it checks if there is a signal. There is. So, it handles the signal
>	and exits (no signal handling routine set).
>
>The catch is that the process went to sleep before we change its priority.
>In this case sleep goes different route and does a simple return. 
>Therefore, we will continue execute the driver code, which may be dangerous!
>
>>What is needed is an exception routine that understands =exactly=
>>what to do to reset the resource to some well-defined state for any
>>possible state the resource may be in.
>
>That's the reason why system priority is chosen to begin with.
>So, don't mess with it IF you can convince your professor not to do 
>this project, :-)  But, I guess, it is OK to do "experiment" in school.
>
>On the other hand, this utility can be very useful. If a process is hanging 
>but cannot be killed (sleeping in uninterruptable priority), you have two
>ways to get rid of it: use this utility or reboot the system. That is,
>this utility can be useful, but is DANGEROUS in general!
>
	Since I posted, I have discussed it with him, and we have narrowed
the field considerably.  The only check the modification will do is to see
if a serial device driver is locked.  If so, it will release the serial
device, and kill the process.  Otherwise, it will have a double check
to see if it really should kill the proc, then actually kill it.

	I feel I understand everything much better now, all I have to do
is figure out where in the code to look...  Thanx to all for your help!

	lee


Brought to you by Super Global Mega Corp .com