How are the signals handled in the kernel. What happens internally if I send a kill signal to a kernel thread/process. Does a crash in kernel process means kernel panic always, if not will it generate coredump.
When a thread is running code in kernel mode, signals are queued, i.e. the kernel remembers that a signal has been sent but doesn't act on it. When a kernel thread is waiting for an event, the wait may be interrupted by the signal — it's up to the author of the kernel code. For example, the Linux kernel API has pairs of functions like
wait_event_interruptible; only the “interruptible” function will return immediately if the thread receives a signal.
The reason kernel code isn't interrupted by signals is that it can put kernel memory or hardware devices in an inconsistent state. Therefore the code is always given a chance to clean things up.
Linux's kernel threads (i.e. threads of the kernel, listed with no corresponding executable in process lists) can't receive signals at all. More precisely, any signal delivered to a kernel thread is ignored.
A crash in kernel code may or may not cause a panic, depending on which part of the code caused the crash. Linux, for example, tries to recover from crashes in driver code, but whether this is possible depends on what went wrong. Crashes in kernel code may or may not generate a dump depending on the kernel and on the system configuration; for example Linux has a kernel crash dump mechanism.