PM signal handling check too strict

- this panic may be unnecessarily triggered if PM gets the delayed
  stop signal from kernel before it gets reply from VFS to the UNPAUSE
  call.

- after this change PM does not proceed to delivering the signal until
  the reply from VFS is received. Perhaps PM could deliver the signal
  straight away as it knows that the process does not run. Possibly
 i dangerous.

- the signal is deliverd immediately after the UNPAUSE reply as the
  pending signals are always checked at the moment.

diff --git a/servers/pm/signal.c b/servers/pm/signal.c
index 53d30d1f5c9183e00f5eefb072f61aca8848c1fc..ac2b092f192345dfe2ddf7964df407189feab7bb 100644 (file)
--- a/servers/pm/signal.c
+++ b/servers/pm/signal.c
@@ -264,7 +264,14 @@ PUBLIC int process_ksig(int proc_nr_e, int signo)
   if (signo == SIGSNDELAY && (rmp->mp_flags & DELAY_CALL)) {
        rmp->mp_flags &= ~DELAY_CALL;
 
-       if (rmp->mp_flags & (FS_CALL | PM_SIG_PENDING))
+       /*
+        * If the FS_CALL flag is still set we have a process which is stopped
+        * and we only need to wait for a reply from VFS. We are going to check
+        * the pending signal then
+        */
+       if (rmp->mp_flags & FS_CALL)
+               return OK;
+       if (rmp->mp_flags & PM_SIG_PENDING)
                panic("process_ksig: bad process state");
 
        /* Process as many normal signals as possible. */