See "man sigaction" for the basics of POSIX signal handling.

sending signals:

sys_kill() calls kill_something_info().  In the case of pid > 0, we then call
kill_proc_info(), which looks up the task by pid (under tasklist spinlock), and
does group_send_sig_info(sig, info, p), which does some checks and then
calls __group_send_sig_info().

__group_send_sig_info() first calls handle_stop_signal to handle "stop"
signals (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) and SIGCONT.  Return without
doing anything if the signal is ignored.

Call send_signal:
	queues it up.

Call __group_complete_signal.

See allow_signal() for possibly helpful comment?:
	/* Kernel threads handle their own signals.
           Let the signal code know it'll be handled, so
           that they don't get converted to SIGKILL or
          just silently dropped */

Also read through signal-related stuff in net/sunrpc/sched.c.


When are signals actually *delivered*?

I think in case of kernel threads what happens is:
	use signal_pending(current) to decide if you got a signal.
	Handle it yourself.
	Call flush_signals(current) or something if you want to clear it
		manually.

Unless you explicitly handle signals in this way (and kill is the only one it's
reasonable to), you just ignore signals and they get handled on return to
userspace.  The only way they affect you is if you do a noninterruptible sleep,
this'll affect when and how it returns to you.

Signal delivery itself probably actually happens deep in the
architecture-specific code somewhere.