I seem to be missing something here. If a process is constantly *running* in kernel space, doesn't that mean that the system is stuck? I mean, as of 2.4, being in the middle of a system call means no context switches, unless you put yourself to sleep this way or another?Therefore, when a process is executing in kernel space, it can only be killed if the programmer who wrote the code that it is executing at the moment took care to handle signals. Even if she did, the signal will only be handled at specific points.
And if we go in and out of system calls, shouldn't the process respond to signals?
If this happened on a 2.6 kernel, the explanation would be simple: Spinning in kernel space, and still context switching happens, so system keeps on running. But in 2.4?
You are so right. I just lost 5 points in the exam where I'm supposed to point at where the code got stuck. ;)This is probably a macro, or an inline function. What does it expeand to? It is unlikely that the code gets stuck here - note the irqsave() above - unless this macro/inline function enables IRQs, if the code was "stuck" here, IRQs would be off and the machine would be dead for all intents and purposes.
I'm not so sure about anything anymore, but I think that the for(;;) is was running all the time, and my SysRq thingy happens to work exactly when the interrupts are restored. The reason I think so, is that on four successive snapshots I made, I got exactly the same stack trace, which point at do_IRQ, which traces back to a "popf" command, which is part of the spin_unlock_irqrestore() macro. Hopefully intelligent guess: The restoration of irq triggers off the dump we all look at. That's why we get exactly the same result all the time. It isn't stuck, it's running.
Eli
-- Web: http://www.billauer.co.il
