A blocked system call prevents SIGKILL from killing a process

Question

I have a request regarding signal propagation between kernel threads. The scenario is as follows:

From the application for user space, a system call is made, the kernel creates a thread (lets call it thread1) inside the system call.

Now, inside this thread1, the kernel loops in a while loop and blocks. The main thread also loops in the while loop. If I do "kill -9> user app pid>", the application cannot exit normally. Even the / proc entry still exists. Although the / proc // fd folder becomes empty.

If I put the following in the main threads during the loop, it will correctly catch the signal and exit. If I put only in thread1s while loop only, the main thread still doesn't exit.

if (signal_pending(current)) { return; } 

Can you suggest how the kernel should behave in this case with the kill -9 signal? After SIGKILL, the state of the process becomes Zombie.

The system call has the following implementation:

 thread1 = kthread_create(thread_fn, NULL, "thread1"); if (thread1) { wake_up_process(thread1); } printk(KERN_NOTICE "Main thread: current:%s\n", current->comm); while(1) { DELAY_SEC(1) 

Thread_fn:

 int thread_fn(void* data) { while(1) { DELAY_SEC(1) } } 

Hello,

Sonic

Answer 1

Sending a signal to a process simply sets the appropriate flag for that signal.

When a process returns from kernel mode (for example, when a system call returns), these flags are checked. If one of them has been pre-installed, the corresponding action is performed.

Since your system call never returns, this will never happen.

In other words: you really cannot kill a Linux process. You can just politely ask him to die.