[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-arm-kernel
Subject:    Re: why cannot block inside interrupt context
From:       Tushar <tushar () mwti ! net>
Date:       2005-02-02 12:18:35
Message-ID: 1107345995.16274.38.camel () tushar ! mwti ! net
[Download RAW message or body]

On Sun, 2005-01-30 at 04:36, Baurjan Ismagulov wrote:
> On Thu, Jan 27, 2005 at 04:51:23PM +0900, Li Xinyi wrote:
> > This seems to be a silly question. But I do feel confusion that why 
> > cannot do block inside interrupt. In terms of ARM kernel, isnt that safe 
> > to do block inside interrupt, or it is just a bad practice? Rather than 
> > accept it as a general rule, can anyone explain why?
> 
> I think the reason is that as schedule() jumps to the user space of
> another process, you don't have kernel stack with the return address to
> your ISR any more. When this process calls kernel, a new kernel stack is
> used. Consider, for example, the following scenario:
> 
> 1. Pid 100 runs in user space.
> 2. Your interrupt occurs. The kernel uses pid 100's kernel stack.
> 3. You call schedule() directly or indirectly.
	If it sleeps for ever inside interrupt then I think schedule() 
	will not be called. As I know (I may be wrong also, but according to
books i have understood) , scheduling will happen only after interrupt
handling function returns. 

	If i have such a interrupt handling function 
	
	handle_irq()
	{
	finish my work;
	enable interrupt;
	sleep for ever;
	}
	
(Li , If u don't mean something like this, please let me know),
	then 
	1. Process with pid 100 is running.
	2.Interrupt arrives, register are saved and control transfers to above
function. 
	3.It never returns.
	4.Other interrupt arrives, current registers are saved. goto 2. 

This way, each time a interrupt will come, it will just save process
registers and stack will overflow after enough interrupt. So say after N
interrupts, there will be N+1 stack frames saved, One for context of
process and others for context of interrupt handler.This way it will 
become recursive.  Needs little thinking for situation where some other
type of interrupt can also arrive.

	It feels good to go back to theory after leaving collage.

Regards,
Tushar
	
	

		
> 4. schedule() jumps to pid 200.
> 5. Pid 200 runs and issues a system call. The kernel uses pid 200's
>    kernel stack.
> 6. The kernel decides to schedule() pid 100.
> 7. Pid 100 runs and issues a system call. The kernel uses pid 100's
>    kernel stack (from the highest address, not from the address after
>    step 4).
> 
> So, the rest of your ISR is not going to be processed. I cannot say what
> are the consequences of that, perhaps others may comment on that. But it
> seems that if you manage to leave the hardware in a sane state before
> step 3, everything except your driver is going to work just fine.
> 
> This is my understanding of the issue, corrections are welcome.
> 
> With kind regards,
> Baurjan.
> 
> -------------------------------------------------------------------
> Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
> Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
> 



-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
[prev in list] [next in list] [prev in thread] [next in thread]