Signal delivery to kernel threads/processes?

[Don Lewis]

On 16 Jan, Robert Watson wrote:
> 
> Bill Paul raised an interesting question with me recently -- he observed
> that a userspace process running with root privileges could deliver a
> signal to a kthread, and that this might produce undesired behavior.  I
> was sure that, at some point, we had a check disallowing this, but I don't
> see it in either RELENG_4 or HEAD.  Do we rely on the ability to
> send/receive signals to interrupt kthreads, that we know of?  While the
> signal delivery itself doesn't make sense, waking up a tsleep() with
> PCATCH could well be useful behavior.  Should a kthread have to declare if
> it wants to receive interruptions?  Given plans, at some point, to make
> kthreads be real threads, and be part of a kernel process, that would
> raise some challenges for code relying on the ability to be interrupted
> with a signal in kernel space, as signals generated by kill() are
> targetted at processes, not threads.
> 
> Any thoughts?  It's tempting simply to add the following to cr_cansignal()
> to at least disallow sourcing the signals in userspace:
> 
> 	if (p->p_flag & P_SYSTEM)
> 		return (EPERM);
> 
> But I don't have a broad enough view of what goes on in the kernel to
> reason about what disasters this might cause if signalling is relied on. 

The only thing I worried about is what happens to kthreads on
shutdown.  It looks like this is handled by kthread_suspend() which
tells the thread that it has received a SIGSTOP, but this isn't done
with the normal signal delivery mechanism.