kernel thread and signal handling

How does kernel thread handle signals? Or will they handle signals?
I mean "kernel thread",not "user thread".

this is one of those things i imagine you will find lots of argument about and i'm really not sure, exactly sure, whats happening in the kernel right now.

kernel thread signals are generally considered a horrible evil and signals are for user space.
rant and rave, rant and rave.
seems like there is a function to set allow_signal() that only allows
SIGKILL otherwise signals are silently dropped. At least that's how it was the last time i looked.

The kernel doesn't "handle" signals per se, other than posting them to userland processes. That being said, there are kernel space processes such as nfsd that need to be able (I assume) to receive signals to shut down, and I'm not totally sure how that works. Kernel threads do have the same sort of process info structure associated with them as userspace programs, IIRC, they just are totally memory mapped into kernel space. So I imagine they can access their own signal table and set up "handlers" within the kernel. This is more my intuition based on my understanding of how the kernel works rather than something I've actually researched, so I may be wrong on this.

Note that things are different in kernel mode. If you have an unrecoverable page fault in the kernel, you generally crash the system.

"Use the Source, Luke!"

A good example of a kernel thread that does more-than-trivial things is found in fs/lockd/svc.c.

This is a "lock management daemon" that interacts with user-land processes in interesting ways and thus should serve as an interesting example.

Other daemons, like the swap-daemon in mm/vmscan.c, are pretty much self-contained, interacting only with the kernel and basically serving as a vehicle for doing I/O.

The fundamental reason for kernel-threads, and for mechanisms like "keventd" (kernel/context.c), is to be able to do things asynchronously in a kernel-context. You see, if you think about it, in many ways the kernel is just a great big subroutine-library, called to do various things which it does in the context of whatever process called them. But some things that it has to do are asynchronous in nature, not linked closely to any particular user-land process, and ... how do you handle these things, and (we would like) handle them elegantly? The concept of having a "dispatchable, schedulable, basically-autonomous thing" that is nonetheless "fully part of the kernel" is a way of doing that.