Subject: Re: make proc_stop kernel-public
To: None <tech-kern@netbsd.org>
From: Simon Burge <simonb@wasabisystems.com>
List: tech-kern
Date: 11/15/2003 11:45:42
Emmanuel Dreyfus wrote:

> [ LWPs and proc states ]

The reminds me...

In the 1.6 psignal() (in kern/kern_sig.c) we had:

        switch (p->p_stat) {
        case SSLEEP:
		...
        case SSTOP:
		...
#ifdef __HAVE_AST_PERPROC
        case SONPROC:
        case SRUN:
        case SIDL:
                /*
                 * SONPROC: We're running, notice the signal when
                 * we return back to userspace.
                 *
                 * SRUN, SIDL: Notice the signal when we run again
                 * and return to back to userspace.
                 */
                signotify(p);
                goto out;

        default:
                /*
                 * SDEAD, SZOMB: The signal will never be noticed.
                 */
                goto out;
#else /* ! __HAVE_AST_PERPROC */
        case SONPROC:
                /*
                 * We're running; notice the signal.
                 */
                signotify(p);
                goto out;

        default:
                /*
                 * SRUN, SIDL, SDEAD, SZOMB do nothing with the signal.
                 * It will either never be noticed, or noticed very soon.
                 */
                goto out;
#endif /* __HAVE_AST_PERPROC */

Now we have:

        if (p->p_stat == SACTIVE) {
		...
        } else if (p->p_stat == SSTOP) {
		...
        } else {
                /* Else what? */
                panic("psignal: Invalid process state %d.", p->p_stat);
        }

This causes lossage if we have a process that sets up an fd with SIGIO
notification and then forks and gets a signal before the fork finishes (an
example is ntpd with a PPS refclock).

I've been running with the panic replaced with just "goto out;" and it
seems to be working fine (ie, doesn't panic and ntpd works).  Is this
the right change and ok to commit?  Or do we need the signotify() call
for the cases mentioned above?

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/