From: "Nikita V. Youshchenko" <yoush@cs.msu.su>
To: linux-kernel@vger.kernel.org
Subject: CONFIG_PREEMPT x86 assembly question
Date: Sat, 20 Nov 2004 17:43:11 +0300 [thread overview]
Message-ID: <200411201746.44804@sercond.localdomain> (raw)
-----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-----
next reply other threads:[~2004-11-20 14:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-20 14:43 Nikita V. Youshchenko [this message]
2004-11-22 22:10 ` CONFIG_PREEMPT x86 assembly question Michal Schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200411201746.44804@sercond.localdomain \
--to=yoush@cs.msu.su \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox