Possible kernel stack overflow due to fast interrupts

Possible kernel stack overflow due to fast interrupts

[Rick Tao]

Hi, all,

I am looking at the kernel source of 2.6.32. It appears to me that kernel stack can be easily getting overflowed in case of fast interrupts. Here is my observation, any comments? Thanks,

Let's assume task A triggers the fast interrupts, and task B was running when the fast interrupt occur. 

In the context of task B (according to entry_32.S)
0. Assume task B's ksp = X
1. the interrupt causes exception, allocate exception frame space from
   the task B'stack (ksp = X - INT_FRAME_SIZE).
2. interrupt handler is invoked
3. ret_from_except, and resume_kernel is invoked
4. then preempt_schedule_irq is called, which in trun, __schedule() and 
   context_switch is called. Assume it switches to task A. 
   In this step,
     task B's stack is pushed another INT_FRAME_SIZE to save its context,
     so task B's ksp = X - 2 * INT_FRAME_SIZE now.

In the context of task A
a. NIP would point to the instruction after switch_to(). 
b. MSR_EE is enabled in the call trace (finish_task_switch -->finish_lock_switch-->spin_unlock_irq)
c. do something that would trigger an interrupt later on (such as timer)
d. call schedule() for context switch to task B.
   In this step, 
     task B's stack is popped INT_FRAME_SIZE size for context restore.  
   Note that task B's ksp = X - INT_FRAME_SIZE

In the context of task B again
a1. similar to step "a" above
b1. similar to step "b" above 
c1. interrupt occurs, go to step "1" above, and repeat!!!

As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE
on each loop. It will eventually overflow.

Thanks for your input.

Rick





      

Re: Possible kernel stack overflow due to fast interrupts

[Benjamin Herrenschmidt]

On Thu, 2010-10-14 at 13:45 -0700, Rick Tao wrote:
> Hi, all,

 .../...

> In the context of task A
> a. NIP would point to the instruction after switch_to(). 
> b. MSR_EE is enabled in the call trace (finish_task_switch -->finish_lock_switch-->spin_unlock_irq)
> c. do something that would trigger an interrupt later on (such as timer)
> d. call schedule() for context switch to task B.
>    In this step, 
>      task B's stack is popped INT_FRAME_SIZE size for context restore.  
>    Note that task B's ksp = X - INT_FRAME_SIZE
> 
> In the context of task B again
> a1. similar to step "a" above
>
> b1. similar to step "b" above 
> c1. interrupt occurs, go to step "1" above, and repeat!!!
> 
> As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE
> on each loop. It will eventually overflow.

So if I follow you correctly, you are worried that by the time execution
resumes in B, and before it pops the second frame off, it might get
another interrupt and re-preempt...

Now unless I missed something, that cannot happen because
preempt_schedule_irq() does increment the preempt count:

	add_preempt_count(PREEMPT_ACTIVE);
	local_irq_enable();
	schedule();
	local_irq_disable();
	sub_preempt_count(PREEMPT_ACTIVE);

Which means that it won't preempt again in finish_task_switch, and so
will eventually come back, turn EE back off, and pop off the stack
frame.

Or am I missing something ?

Cheers,
Ben.

Re: Possible kernel stack overflow due to fast interrupts

[Rick Tao]

You are exactly right! Ensuring interrupts would not cause more preemptions=
. =0AThanks for pointing it out.=0ARick=0A=0A--- On Thu, 10/14/10, Benjamin=
 Herrenschmidt <benh@kernel.crashing.org> wrote:=0A=0A> From: Benjamin Herr=
enschmidt <benh@kernel.crashing.org>=0A> Subject: Re: Possible kernel stack=
 overflow due to fast interrupts=0A> To: "Rick Tao" <tao_rick@yahoo.com>=0A=
> Cc: linuxppc-dev@lists.ozlabs.org=0A> Date: Thursday, October 14, 2010, 4=
:57 PM=0A> On Thu, 2010-10-14 at 13:45 -0700,=0A> Rick Tao wrote:=0A> > Hi,=
 all,=0A> =0A>  .../...=0A> =0A> > In the context of task A=0A> > a. NIP wo=
uld point to the instruction after=0A> switch_to(). =0A> > b. MSR_EE is ena=
bled in the call trace=0A> (finish_task_switch=0A> -->finish_lock_switch-->=
spin_unlock_irq)=0A> > c. do something that would trigger an interrupt late=
r=0A> on (such as timer)=0A> > d. call schedule() for context switch to tas=
k B.=0A> >=A0 =A0 In this step, =0A> >=A0 =A0 =A0 task B's stack is popped=
=0A> INT_FRAME_SIZE size for context restore.=A0 =0A> >=A0 =A0 Note that ta=
sk B's ksp =3D X -=0A> INT_FRAME_SIZE=0A> > =0A> > In the context of task B=
 again=0A> > a1. similar to step "a" above=0A> >=0A> > b1. similar to step =
"b" above =0A> > c1. interrupt occurs, go to step "1" above, and=0A> repeat=
!!!=0A> > =0A> > As you can see, task B's kernel stack space is reduced=0A>=
 by INT_FRAME_SIZE=0A> > on each loop. It will eventually overflow.=0A> =0A=
> So if I follow you correctly, you are worried that by the=0A> time execut=
ion=0A> resumes in B, and before it pops the second frame off, it=0A> might=
 get=0A> another interrupt and re-preempt...=0A> =0A> Now unless I missed s=
omething, that cannot happen because=0A> preempt_schedule_irq() does increm=
ent the preempt count:=0A> =0A> =A0=A0=A0 add_preempt_count(PREEMPT_ACTIVE)=
;=0A> =A0=A0=A0 local_irq_enable();=0A> =A0=A0=A0 schedule();=0A> =A0=A0=A0=
 local_irq_disable();=0A> =A0=A0=A0 sub_preempt_count(PREEMPT_ACTIVE);=0A> =
=0A> Which means that it won't preempt again in=0A> finish_task_switch, and=
 so=0A> will eventually come back, turn EE back off, and pop off=0A> the st=
ack=0A> frame.=0A> =0A> Or am I missing something ?=0A> =0A> Cheers,=0A> Be=
n.=0A> =0A> =0A> _______________________________________________=0A> Linuxp=
pc-dev mailing list=0A> Linuxppc-dev@lists.ozlabs.org=0A> https://lists.ozl=
abs.org/listinfo/linuxppc-dev=0A> =0A=0A=0A