From d3e991a7b60752bc32fa51b8fcfe55b9245006e3 Mon Sep 17 00:00:00 2001 From: Tomas Hruby Date: Mon, 10 May 2010 14:27:22 +0000 Subject: [PATCH] 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. --- servers/pm/signal.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/servers/pm/signal.c b/servers/pm/signal.c index 53d30d1f5..ac2b092f1 100644 --- 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. */ -- 2.44.0