On Fri, Dec 26, 2003 at 02:29:58PM +0200, Eli Billauer wrote:

> Yes. Catch point marked in code snippet at the end of this message. Note 
> that it survived the spinlock. And this specific code piece remains 
> intact as of 2.6.0-test4.
> 
> This little discussion still hasn't answered my first, and most 
> interesting question: How can a process be running, and yet not 
> killable. 

I thought I answered that in the first mail. Let's try again:
- to kill a process, you send it a signal
- in user space, some signals are handled and cannot be ignored or
"deflected" by the programmer
- in kernel space, signals are only handled at the discretion of the
programmer


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. 

>I mean, as of 2.4, if it's stuck in the middle of a system 
> call, within the kernel, I would expect the system to freeeze (with no 
> oops). But if context is switched every now and then, I would expect the 
> OS to check for signals. After all, it's not the process that volunteers 
> to kill itself. It's the system that kills it.

signals aren't automatically checked at ctx-switch time, to the best
of my recollection, only at system call entry and exit. 

> Another thing that makes me wonder, is that according to the source, 
> there's a recurring check for pending signals. But since this code is 
> run under the graces of kernel_lock() (in i810_release(), which calls 
> the drain_dac), I wonder if this is not related to the problem.

>        spin_lock_irqsave(&state->card->lock, flags);
>        i810_update_ptr(state); <----------------- This is where it was 
> caught! ---------------

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. 

Cheers, 
Muli 
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

"the nucleus of linux oscillates my world" - [EMAIL PROTECTED]

Attachment: signature.asc
Description: Digital signature

Reply via email to