sanchayanmaity/minix
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

PM signal handling check too strict

Browse source 
- 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.
This commit is contained in:
Tomas Hruby 2010-05-10 14:27:22 +00:00
parent 5c63cac05a
commit d3e991a7b6
1 changed files with 8 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
servers/pm/signal.c
View file

@ -264,7 +264,14 @@ PUBLIC int process_ksig(int proc_nr_e, int signo)
if (signo == SIGSNDELAY && (rmp->mp_flags & DELAY_CALL)) { if (signo == SIGSNDELAY && (rmp->mp_flags & DELAY_CALL)) {
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"); panic("process_ksig: bad process state");
/* Process as many normal signals as possible. */ /* Process as many normal signals as possible. */