Re: kernel preemption while returning from interrupts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/30/06, Joe Knapka <jknapka@xxxxxxxxxxxxx> wrote:
> Gaurav Dhiman wrote:
>
> >Can someone explain me the following doubt:
> >
> >177 #ifdef CONFIG_PREEMPT
> >178 ENTRY(resume_kernel)
> >179         cli
> >180         cmpl $0,TI_preempt_count(%ebp)  # non-zero preempt_count ?
> >181         jnz restore_all
> >182 need_resched:
> >183         movl TI_flags(%ebp), %ecx       # need_resched set ?
> >184         testb $_TIF_NEED_RESCHED, %cl
> >185         jz restore_all
> >186         testl $IF_MASK,EFLAGS(%esp)     # interrupts off (exception path) ?
> >187         jz restore_all
> >188         call preempt_schedule_irq
> >189         jmp need_resched
> >190 #endif
> >
> >I have observed that while returning from interrupts or exceptions
> >(ret_from intr() assembly code in entry.S), if we are moving back to
> >kernel execution path, we jump to 'resume_kernel', which in turn
> >checks the following things:
> >
> >1) Can we preempt (means current->preempt_count == 0)
> >2) if 1st point is true, we check, do we need to reschedule (means
> >current->need_resched is set).
> >3) if 2nd condition is also true (means we need to reschedule), then
> >we check are the intterupts disabled.
> >
> >If interrupts are disabled, we restore the registers and go back to
> >interrupted kernel execution path, else we call function
> >'preempt_schedule_irq()', which do the kernel preemption.
> >
> >My question is when we are deliberatly disabling the interrupts at
> >line 179 above, why do we check for interrupts disabled, they will
> >always be disabled, hence preemption will never be done while
> >returning from interrupts or exceptions.
> >
> >I think I am missing something .... please let me know the answer.
> >
> >
> Other places in the kernel jump directly to need_resched, so line 179
> may not have been executed in the code path that reached line 186.

I was expecting this response from someone, well I that is fine.
I think I should repharse my question as follows:

Why dont we consider preemption while returning from interrupts or exceptions ??

Whenever we will return to kernel execution path from exception or
interrupt, we will follow the path from 'resume_kernel', which
actually disables the interrupts by cli statement, due to which we
never consider preemption as possibility at check made at line 186

while returning to kernel from exception or interrupt, why dont we
enable the interrupts (statment sti in place of cli) and do the
preemption if needed. Is there any harm in this ??

If we are not doing preemption or not considering it at all while
returing to kernel execution path from interrupts or exception, where
else we are considering the preemption. We definitely can not and are
not considering the preemption while returning from system call as in
that we will always be returing to user mode.

-Gaurav

>
> Cheers,
>
> -- JK
>
>
>

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux