Use of sti in entry.S question

Use of sti in entry.S question

[Duncan Sands]

2.5/arch/i386/kernel/entry.S:

In work_resched, schedule may be called with
interrupts off:

work_resched:
        call schedule
        cli                             # make sure we don't miss an interrupt
                                        # setting need_resched or sigpending
                                        # between sampling and the iret
        movl TI_FLAGS(%ebp), %ecx
        andl $_TIF_WORK_MASK, %ecx      # is there any work to be done other
                                        # than syscall tracing?
        jz restore_all
        testb $_TIF_NEED_RESCHED, %cl
        jnz work_resched <====== schedule with interrupts disabled

Is this a mistake or an optimization?  Elsewhere in entry.S, interrupts
are turned on before calling schedule:

#ifdef CONFIG_PREEMPT
ENTRY(resume_kernel)
        cmpl $0,TI_PRE_COUNT(%ebp)      # non-zero preempt_count ?
        jnz restore_all
need_resched:
        movl TI_FLAGS(%ebp), %ecx       # need_resched set ?
        testb $_TIF_NEED_RESCHED, %cl
        jz restore_all
        testl $IF_MASK,EFLAGS(%esp)     # interrupts off (exception path) ?
        jz restore_all
        movl $PREEMPT_ACTIVE,TI_PRE_COUNT(%ebp)
        sti <====== schedule with interrupts enabled
        call schedule
        movl $0,TI_PRE_COUNT(%ebp)
        cli
        jmp need_resched
#endif

Thanks,

Duncan.

Re: Use of sti in entry.S question

[Andi Kleen]

Duncan Sands <baldrick@wanadoo.fr> writes:

> 2.5/arch/i386/kernel/entry.S:
> 
> In work_resched, schedule may be called with
> interrupts off:
> 
> work_resched:
>         call schedule
>         cli                             # make sure we don't miss an interrupt
>                                         # setting need_resched or sigpending
>                                         # between sampling and the iret
>         movl TI_FLAGS(%ebp), %ecx
>         andl $_TIF_WORK_MASK, %ecx      # is there any work to be done other
>                                         # than syscall tracing?
>         jz restore_all
>         testb $_TIF_NEED_RESCHED, %cl
>         jnz work_resched <====== schedule with interrupts disabled
> 
> Is this a mistake or an optimization?  Elsewhere in entry.S, interrupts
> are turned on before calling schedule:

It's a mistake, but a harmless one. The scheduler turns off interrupts
soon itself and the instructions it executes before that don't care.
The only reason it's not recommended to call schedule with interrupts
off is that the scheduler will turn them on again, usually breaking
your critical section. In this case it's ok because the next
instrution is a cli again.

-Andi

Re: Use of sti in entry.S question

[Duncan Sands]

...
> > Is this a mistake or an optimization?  Elsewhere in entry.S, interrupts
> > are turned on before calling schedule:
>
> It's a mistake, but a harmless one. The scheduler turns off interrupts
> soon itself and the instructions it executes before that don't care.
> The only reason it's not recommended to call schedule with interrupts
> off is that the scheduler will turn them on again, usually breaking
> your critical section. In this case it's ok because the next
> instrution is a cli again.

Do you think it's worth pushing this fix?

diff -Nru a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S	Thu May 22 22:45:50 2003
+++ b/arch/i386/kernel/entry.S	Thu May 22 22:45:50 2003
@@ -306,6 +306,7 @@
 	testb $_TIF_NEED_RESCHED, %cl
 	jz work_notifysig
 work_resched:
+	sti
 	call schedule
 	cli				# make sure we don't miss an interrupt
 					# setting need_resched or sigpending