Very Computer

        As a class project, I am working on a modification to the
BSD 4.3 source code to allow one to kill uninteruptable processes.

        It would seem that we are at a bit of a standpoint.  Initially,
I thought that I could have the kernel raise the priority of the suspect
process in the psignal() call, which after setting it to run, would
allow the process to release the resources it was sleeping with, and
exit gracefully, as I would post the kill signal before letting it run
again.  The others in my group have questioned this, and now I have
begun to wonder if it will work.

        Will the above method cause a race condition resulting from
the fact that the process probably assumes that the next time it runs
it will have the resource it was sleeping on?  And if so, I would
appreciate some other suggestions as to how to solve this problem.

        thanx
-- lee

------------randomly-chosen-drink/quote/simpsons'-quote---------------
"If you choose not to decide you still have made a choice."
                - Geddy Lee

Just for kicks, imagine some real slow device has been set up to
do a DMA transfer to some physical address that is held by the
process which is unkillable.  Imagine that you kill that process
and it exits.  Imagine the I/O completes and someone elses
memory gets trashed.  All that and more ...
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh

"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.

(rest deleted)

A while back (~4-5 yrs) Chris Torek (I think) produced a nice little
patch to the 4.3 kernel to kill groups of run away (and rapidly
spawning) processes - this was the 'zonk' system call. You could probably
gain an insight into your problem by looking at this. The catch is that
I don't have access to the machine that I installed the patch on.

Zonk was very useful, especially on Student/teaching machines - one could
guarantee that some bright spark would experiement with self spawining
processes, zonk would kill all jobs owned by a particular UID stone dead.

Neil

The first class you probably shouldn't mess with. If you're lucky,
removing the sleeping process will only result in the loss of some
buffer. In worse cases, you get permanently un-openable devices or
crashes. The real cure for these is to rewrite _each_case_ to sleep at
interruptible priority and clean up properly (more than a class
project, I think).

For the second class, the real problem is that the kill signal is
blocked inside the exit call. If you put some signal-catching code in
exit, you can delay this blocking until after the open files are
closed. This may allow some slow devices to closed in an irregular
way, but that possibility already exists in the case of explicit close
calls.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn

Quote:>Just for kicks, imagine some real slow device has been set up to
>do a DMA transfer to some physical address that is held by the
>process which is unkillable.  Imagine that you kill that process
>and it exits.  Imagine the I/O completes and someone elses
>memory gets trashed.  All that and more ...

Forcibly awaking a process doing read/write (DMA transter) will either
give the process a buffer with garbage data or throw away a buffer
containing valid data. How can this trash someone else's memory?

Y. Rock Lee, att!cblph!rock

Quote:>The first class you probably shouldn't mess with. If you're lucky,
>removing the sleeping process will only result in the loss of some
>buffer. In worse cases, you get permanently un-openable devices or
>crashes. The real cure for these is to rewrite _each_case_ to sleep at
>interruptible priority and clean up properly (more than a class
>project, I think).

The "permanently un-openable devices" can only happen in the case of open.
Because open wasn't "complete" so the close call in the exit cannot do a
correct clean up. Please correct me if I miss something.

Y. Rock Lee, att!cblph!rock

Y. Rock Lee, att!cblph!rock

Seriously: I never produced this particular bletcherous hack.  (I am
responsible for a number of other, different bletcherous hacks, but
not this one.)  If (A) you have SIGSTOP and (B) signals work correctly,
the super-user can stop everything, pick out the bad processes, kill
them, and then resume everything.  (This is a bit tricky to get right,
admittedly.)
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)

  #include <sys/time.h>
  #include <sys/resource.h>
  #include <signal.h>
  #include <stdio.h>
  #include <errno.h>
  extern int errno;

  main(argc,argv,envp) /* invoke as, e.g., zonk /bin/csh csh -f; untested */
  int argc;
  char *argv[];
  char *envp[];
  {
   if (getuid()) { fprintf(stderr,"zonk: fatal: uid not 0\n"); exit(1); }
   if (geteuid()) { fprintf(stderr,"zonk: fatal: euid not 0\n"); exit(2); }
   if (setpriority(PRIO_PROCESS,0,-20))
     fprintf(stderr,"zonk: weird: can't set my priority to -20\n");
   if (kill(-1,SIGSTOP) == -1) perror("zonk: warning: first kill failed");
   if (kill(-1,SIGSTOP) == -1) perror("zonk: warning: second kill failed");
   if (kill(-1,SIGSTOP) == -1) perror("zonk: warning: good-luck kill failed");
   for (;;)
    {
     (void) execve(argv[1],argv + 2,envp);
     perror("zonk: critical: exec failed, will try again");
     sleep(60);
    }
  }

---Dan

This has been the case forever (well, at least since V7) - when you come
out of a sleep(), you *must* check that the reason you were sleeping is
no longer true....

--Pat.

Quote:>Yes, the process will think it has the resource it was sleeping on.
>But, it will be killed and release the resource during its exit
>before it has a chance to "think". This part looks OK to me.
>My only concern is that the driver of the particular device which
>the process is waiting for may react crazily when it is misinformed
>(a good driver should guard against this).

A typical sleep loop looks something like

        while (some_status & some_busy_flag)
                sleep (&some_status, PRI_O_MINE);

        some_status |= some_busy_flag;

If your only concern is getting this process to ignore the setting
of "some_busy_flag", you might be doing the right thing - but
remember - "some_status" still has the "some_busy_flag" set.  Killing
the process will not get that bit clear and if that bit being set
is what is* the process, the next process to enter that loop
is also going to hang.

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.
--
John F. Haugh II      |      I've Been Moved     |    MaBellNet: (512) 838-4340
SneakerNet: 809/1D064 |          AGAIN !         |      VNET: LCCB386 at AUSVMQ
BangNet: ..!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)

Quote:>Forcibly awaking a process doing read/write (DMA transter) will either
>give the process a buffer with garbage data or throw away a buffer
>containing valid data. How can this trash someone else's memory?

        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!

Quote:>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.

On the other hand, this utility can be very useful. If a process is*
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!

Y. Rock Lee, att!cblph!rock

Quote:>Forcibly awaking a process doing read/write (DMA transter) will either
>give the process a buffer with garbage data or throw away a buffer
>containing valid data. How can this trash someone else's memory?

        VOILA - corrupted stuff in the new process.
--
---------------
uunet!tdatirv!sarima                            (Stanley Friesen)

Quote:

>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*
>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!

        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