`kill -9` on a process blocked on a syscall does kill the process, it just doesn't clean the process up. The result of SIGKILL-ing (i.e., killing with -9) a blocked process is a zombie process. Zombies are dead, right?
You're right, signal delivery does not interrupt an atomic operation, so if
a syscall takes unusually long time (like network filesystems sometimes
cause), the process hasn't received its SIGKILL yet.
This 10000X over. I have an SSD that I have to assume is bad that had abyssal read/write speeds due to processes constantly getting stuck in state D when they touched it. It would bring the system to its knees with load averages 40+ while my 8c/16t CPU would be sitting there doing nothing.
Wrong. If a Linux process is blocked in an uninterruptible system call (typically for disk I/O), it cannot be killed, even with -9.
I have been unable to cleanly shut down Linux systems in the past due to processes getting stuck in this state.