[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:       Baurjan Ismagulov <ibr () ata ! cs ! hun ! edu ! tr>
Date:       2005-01-29 23:06:18
Message-ID: 20050129230618.GA15903 () radix50 ! net
[Download RAW message or body]

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.
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
[prev in list] [next in list] [prev in thread] [next in thread]