Messages in this thread | | | From | "Nikita V. Youshchenko" <> | Subject | CONFIG_PREEMPT x86 assembly question | Date | Sat, 20 Nov 2004 17:43:11 +0300 |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello
Whily lazy-examining kernel code, I found the following interesting point.
In arch/i386/kernel/entry.S
... ENTRY(resume_kernel) cmpl $0,TI_preempt_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_preempt_count(%ebp) sti call schedule movl $0,TI_preempt_count(%ebp) cli jmp need_resched #endif ...
Why, after return from schedule(), first 0 is written to TI_preempt_count(%ebp), and only then interrupts are disabled? Wht not the reverse order?
As far as I understand, the idea of the preempt_count flag is to avoid nested preemts. The fact that flag is reset before interrupts are disabled, somewhat breaks this: interrupt may happen just after flag is reset, causing nested interrupt while preempt_count flag is already reset. In a very unprobable case this could happen unlimited number of times, causing kernel stack overflow.
Very unprobable? But couldn't this be the cause of kernel lockups I suffered several times while writing DVD on a probably broken media (which could cause interrupt storm)?.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBn1jSv3x5OskTLdsRAu/lAKCCqeNbJSkhC4W3iWawjm4vctOzpwCeN7vX Cjk39KRgRSnjN8ktKGCfoUA= =XvKR -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |