MIPS Interrupts.

MIPS Interrupts.

[Kapoor, Pankaj]

All,

While studying the implementation of tasklets and softirq processing I came 
across certain issues which I have outlined below. 

The function mipsIRQ in the file mipsIRQ.s is the registered interrupt 
handler for all general purpose interrupts. 

The first thing that the function does is that it saves all registers. It 
then checks the CAUSE register to check the source of the interrupt.
Currently 
all we are interested in is INT5 (Timer) and INT0 (i.e. all other devices) 

Consider a timer interrupt which would cause the code to jump to 0x8000:0180

and cause all the registers to be saved (SAVE_ALL). It would then jump to
the 
mips_timer_interrupt function in the file time.c 

The function services the timer interrupt. At the end of the function there 
is an irq_exit and a check to see if there are any SOFT IRQ pending. 
If there are any the function jumps to the do_softirq function defined in 
the softirq.c. The function gets the softirq pending list, enables
interrupts 
and cycles through all pending soft irq's calling the appropriate handlers. 

Remember that the interrupts are enabled while executing the various bottom 
half handlers. 

Now there are 2 cases that can happen 

1. Since we have not exited the ISR and the exception level has still not 
   been restored there can be no more interrupts that are generated in the 
   system. In such a case does that mean that the all bottom half handlers 
   pending execution will run with interrupts disabled. 
   NOTE: This does not seem likely because the local_irq_enable routine
calls 
   _sti which clears the exception level in the status register and also 
   sets the IE bit. 

2. If we have large number of tasklets or if the bottom half handlers take
time 
   to execute, then we could get another timer interrupt or other device 
   interrupts causing context saves which would cause the stack to grow and 
   CRASH the system. 
  
Context is restored only when the code returns from do_softirq and uses the 
ret_from_irq. 

Is there anything that I am missing in this whole picture ? 

Thanks.
- Pankaj 

Re: MIPS Interrupts.

[Jun Sun]

On Tue, Nov 25, 2003 at 04:52:20PM -0500, Kapoor, Pankaj wrote:
> All,
> 
> While studying the implementation of tasklets and softirq processing I came 
> across certain issues which I have outlined below. 
> 
> The function mipsIRQ in the file mipsIRQ.s is the registered interrupt 
> handler for all general purpose interrupts. 
> 
> The first thing that the function does is that it saves all registers. It 
> then checks the CAUSE register to check the source of the interrupt.
> Currently 
> all we are interested in is INT5 (Timer) and INT0 (i.e. all other devices) 
> 
> Consider a timer interrupt which would cause the code to jump to 0x8000:0180
> 
> and cause all the registers to be saved (SAVE_ALL). It would then jump to
> the 
> mips_timer_interrupt function in the file time.c 
> 
> The function services the timer interrupt. At the end of the function there 
> is an irq_exit and a check to see if there are any SOFT IRQ pending. 
> If there are any the function jumps to the do_softirq function defined in 
> the softirq.c. The function gets the softirq pending list, enables
> interrupts 
> and cycles through all pending soft irq's calling the appropriate handlers. 
> 
> Remember that the interrupts are enabled while executing the various bottom 
> half handlers. 
> 
> Now there are 2 cases that can happen 
> 
> 1. Since we have not exited the ISR and the exception level has still not 
>    been restored there can be no more interrupts that are generated in the 
>    system. In such a case does that mean that the all bottom half handlers 
>    pending execution will run with interrupts disabled. 
>    NOTE: This does not seem likely because the local_irq_enable routine
> calls 
>    _sti which clears the exception level in the status register and also 
>    sets the IE bit. 
>

Refer to your own note.  It is more correct.  :)
 
> 2. If we have large number of tasklets or if the bottom half handlers take
> time 
>    to execute, then we could get another timer interrupt or other device 
>    interrupts causing context saves which would cause the stack to grow and 
>    CRASH the system. 
>   
> Context is restored only when the code returns from do_softirq and uses the 
> ret_from_irq. 
> 

The nested interrupt call, do_IRQ(), may still try to call do_softirq() but
that it will return immediately as it discovers another instance of do_softirq()
is running.  No further nesting occurs as a result. 

Jun

Re: MIPS Interrupts.

[Ralf Baechle]

On Tue, Nov 25, 2003 at 04:52:20PM -0500, Kapoor, Pankaj wrote:

> Now there are 2 cases that can happen 
> 
> 1. Since we have not exited the ISR and the exception level has still not 
>    been restored there can be no more interrupts that are generated in the 
>    system. In such a case does that mean that the all bottom half handlers 
>    pending execution will run with interrupts disabled. 
>    NOTE: This does not seem likely because the local_irq_enable routine
>    calls _sti which clears the exception level in the status register and
>    also sets the IE bit. 
> 
> 2. If we have large number of tasklets or if the bottom half handlers take
>    time to execute, then we could get another timer interrupt or other
>    device interrupts causing context saves which would cause the stack to
>    grow and CRASH the system. 

Interrupts are disabled while the respective interrupt handler is running.

  Ralf

RE: MIPS Interrupts.

[Kapoor, Pankaj]

> The nested interrupt call, do_IRQ(), may still try to call do_softirq()
but
> that it will return immediately as it discovers another instance of
do_softirq()
> is running.  No further nesting occurs as a result. 

How is this detected ? Is this the check of "softirq_pending(cpu)" in the
do_softirq() ?

Can we have a case as shown below :

1. Interrupt 1 is generated : Jump to general exception handler
(0x8000:0180)
2. Save the current context
3. Interrupt 1 is processed which schedules tasklet1 for execution.
	softirq_pending(cpu) = TASKLET_SOFTIRQ
4. Interrupts are reenabled.
5. do_softirq : Tasklet1 is executing & softirq_pending(cpu) = 0.
6. -------> Interrupt 2 is generated : Jump to general exception handler
(0x8000:0180)
		6a) Save the current context
		6b) Interrupt2 is processed which schedules tasklet2 for
execution. 
			softirq_pending(cpu) = TASKLET_SOFTIRQ
		6c) Interrupts are reenabled.
		6d) do_softirq : Tasklet2 is executing &
softirq_pending(cpu) = 0.
		6e) ----> Interrupt3 is generated
			.... and so on.
		.
		.
		.
		6f) Context is restored. Return from exception.
.
.
.
7. Context is restored. Return from exception.

Thanks. 
- Pankaj

Re: MIPS Interrupts.

[Jun Sun]

On Wed, Nov 26, 2003 at 12:09:46AM +0100, Ralf Baechle wrote:
> On Tue, Nov 25, 2003 at 04:52:20PM -0500, Kapoor, Pankaj wrote:
> 
> > Now there are 2 cases that can happen 
> > 
> > 1. Since we have not exited the ISR and the exception level has still not 
> >    been restored there can be no more interrupts that are generated in the 
> >    system. In such a case does that mean that the all bottom half handlers 
> >    pending execution will run with interrupts disabled. 
> >    NOTE: This does not seem likely because the local_irq_enable routine
> >    calls _sti which clears the exception level in the status register and
> >    also sets the IE bit. 
> > 
> > 2. If we have large number of tasklets or if the bottom half handlers take
> >    time to execute, then we could get another timer interrupt or other
> >    device interrupts causing context saves which would cause the stack to
> >    grow and CRASH the system. 
> 
> Interrupts are disabled while the respective interrupt handler is running.
>

They are re-enabled for "bottom halves", i.e., in do_softirq().  I think
that is what the sender is worrying about.

Jun

Re: MIPS Interrupts.

[Jun Sun]

On Tue, Nov 25, 2003 at 07:24:18PM -0500, Kapoor, Pankaj wrote:
> > The nested interrupt call, do_IRQ(), may still try to call do_softirq()
> but
> > that it will return immediately as it discovers another instance of
> do_softirq()
> > is running.  No further nesting occurs as a result. 
> 
> How is this detected ? Is this the check of "softirq_pending(cpu)" in the
> do_softirq() ?
> 

No.  It is 

        if (in_interrupt())
                return;


> Can we have a case as shown below :
> 
> 1. Interrupt 1 is generated : Jump to general exception handler
> (0x8000:0180)
> 2. Save the current context
> 3. Interrupt 1 is processed which schedules tasklet1 for execution.
> 	softirq_pending(cpu) = TASKLET_SOFTIRQ
> 4. Interrupts are reenabled.
> 5. do_softirq : Tasklet1 is executing & softirq_pending(cpu) = 0.
> 6. -------> Interrupt 2 is generated : Jump to general exception handler
> (0x8000:0180)
> 		6a) Save the current context
> 		6b) Interrupt2 is processed which schedules tasklet2 for
> execution. 
> 			softirq_pending(cpu) = TASKLET_SOFTIRQ
> 		6c) Interrupts are reenabled.
> 		6d) do_softirq : Tasklet2 is executing &
> softirq_pending(cpu) = 0.

Impossible here, due to the above checking code.  Instead,
Tasklet2 will run by 5) once this interrupt trap returns.

Jun