Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!bloom-beacon!gatech!udel!mmdf
From: Leisner.Henr@xerox.com (Marty)
Newsgroups: comp.os.minix
Subject: cause_sig problems?
Message-ID: <2378@louie.udel.EDU>
Date: 3 May 88 22:10:52 GMT
Sender: mmdf@udel.EDU
Lines: 68

I was just working on putting in Andy's deadlock fixes (posted 3/10/88) and I
wondered about something:

In kernel/system/cause_sig() the following code is executed:

  rp = proc_addr(proc_nr);
  if (rp->p_pending == 0) sig_procs++;	/* incr if a new proc is now pending */
  rp->p_pending |= 1 << (sig_nr - 1);
  inform(MM_PROC_NR);		/* see if MM is free */

Now fs does a sys_kill (which envokes the system task).  I typically use a
callgate to just trap into the kernel, as long as synchronization isn't a
problem.

However, it seems to me a number of tasks/processes can get into cause_sig from
different places (clock, tty and I'm calling it for SIGFPE, SIGSEGV and SIGILL).

The signals are unraveled via inform() which contains:
	if (rp->p_pending != 0) {
		m.m_type = KSIG;
		m.PROC1 = rp - proc - NR_TASKS;
		m.SIG_MAP = rp->p_pending;
		sig_procs--;
		if (mini_send(HARDWARE, proc_nr, &m) != OK) 
			panic("can't inform MM", NO_NUM);
		rp->p_pending = 0;	/* the ball is now in MM's court */
		return;
	}

It seems possible for signal's to get lost here.

It seems like manipulated p_pending and sig_procs should be treated like
critical sections, so I'm thinking of:

	lock();
	if (rp->p_pending == 0) sig_procs++;	/* incr if a new proc is now pending */
 	 rp->p_pending |= 1 << (sig_nr - 1);
	 unlock();

and
	lock();
	if (rp->p_pending != 0) {
		m.m_type = KSIG;
		m.PROC1 = rp - proc - NR_TASKS;
		m.SIG_MAP = rp->p_pending;
		sig_procs--;
		rp->p_pending = 0;	/* the ball is now in MM's court */
		unlock();
		if (mini_send(HARDWARE, proc_nr, &m) != OK) 
			panic("can't inform MM", NO_NUM);
		
		return;
	}
	unlock();
	
	
I haven't done an exhaustive analysis on the consequences, but something in
there just don't seem right.

The other alternative would be to have a cause_sig entry in the system task and
let the message passing allow only one at a time to be processed.  
Comments?

marty
ARPA:	leisner.henr@xerox.com
GV:  leisner.henr
NS:  martin leisner:henr801c:xerox
UUCP:	nsc!nscimg!amps!marty