You are exactly right! Ensuring interrupts would not cause more preemptions. Thanks for pointing it out. Rick
--- On Thu, 10/14/10, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > From: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Subject: Re: Possible kernel stack overflow due to fast interrupts > To: "Rick Tao" <tao_r...@yahoo.com> > Cc: linuxppc-dev@lists.ozlabs.org > Date: Thursday, October 14, 2010, 4:57 PM > 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. > > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev