System calls and scheduling

Michael Clarke (
Thu, 5 Mar 1998 09:45:30 -0000

Hello all LINUX kernel kings !

Okay, Im beaten ! Im studying the LINUX kernel sources (v2.0.30) in
conjunction with the book "LINUX Kernel Internals" by Beck et al. Im trying
to get a handle on system calls in LINUX and how they tie in with
First Im making a couple of assumptions (which may be wrong !)
1) System calls execute (in _system_call()) with interrupts enabled because
INT 0x80's IDT segment descriptor is of trap gate type (type 15 1111b)
rather than interrupt gate type (as used for h/w interrupts).
2) System calls CANNOT be interrupted by other processes (but they can be
interrupted by h/w interrupts e.g. timer) because other processes cannot
execute* while a system call is in progress, unless the process blocks on
say interruptible_sleep_on() - in which case it is no longer executing

* I want to know why another process cant / doesnt execute while one process
is in the middle of a system call but is not blocked. It looks to me like
the schedule() function could preempt the system_call() for an end of
time-slice event, thus allowing someone else to perform a system call
perhaps racing the pre-empted one.

The reason I say this is because of the way that timer_interrupt() /
do_timer() seems to work...

If the timer interrupt calls ret_from_sys_call() on each timer interrupt
then the timer bottom half is executed and the current process is tested for
quanta expiry i.e. p->counter <0. If resheduling is needed then resched is
set, and ret_from_sys_call() detects this and calls schedule(). This is fine
for processes executing user code. BUT it seems that a process executing a
system call when a timer interrupt is received could also be pre-empted by
quanta expiry, thus a new process is scheduled while one is in mid-flow in a
system call. This breaks my rule 2) above !!!

What *I* see in the code is that do_timer does not check for quanta expiry
(p->counter < 0) until update_process_times() is called. This is in the
bottom half of the timer interrupt and thus will not execute until
ret_from_sys_call() is executed. I do not see a ret_from_sys_call() in the
timer interrupt ISR in the sources. The book says there should be one (as
the timer is a slow interrupt) but does not document it in the code listed.
This means that ret_from_sys_call() would never execute until a process
completes a full system_call() or blocks inside a system call. This means
that processes would never be rescheduled (because the timer interrupt
bottom half is not executed to set need_resched to 1 and then call
schedule()) unless system calls are being executed by processes (as opposed
to calling schedule() at each timer interrupt) --> THIS CANNOT BE CORRECT

Can anyone set me straight on what I have said - what is the correct model
for rescheduling processes particularly in system calls - if this is
actually what happens. Am i making wrong assumptions ? Are there some
devious macros that expand into ret_from_sys_call() or am I just talking
generally crap ?

Cheers for any help offered,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to