Can system calls be interrupted?

Question

Please comment on the following sentence:

On the standard Linux kernel without the rt patch, interrupts can't interrupt ongoing system calls. The reason why our machine doesn't stop working when data is fetched from the hard disk is because the system call we used for that operation is blocking. Blocking means that once it issues the request to the hard disc it changes the process state to blocked, and willingly gives up the processor time. There are no means to interrupt an ongoing system call on a non real time kernel.

This is my understanding of the topic, I am however, not sure if it is correct.

Solution 1

System calls can be interrupted through the use of signals, such as SIGINT (generated by CTRL+C), SIGHUP, etc. You can only interrupt them by interacting with the system calls through a PID, however when using Unix signals and the kill command.

rt_patch & system calls

@Alan asked the following follow-up question:

Is the possibility to interrupt system calls directly related with the acceptance of the rt_patch in the mainline Linux kernel?

My response:

I would think so. In researching this I couldn't find a smoking gun that says you could/couldn't do this which leads me to believe that you can.

The other data point which makes me think this, is that the underlying signals mechanism built into Unix is necessary for being able to interact with processes. I don't see how a system with these patches in place would be able to function without the ability to use signals.

Incidentally the signals operate at the process level. There isn't any method/API which I'm aware of for injecting interrupts to system calls directly.

References

• When and how are system calls interrupted?

Solution 2

Of course interrupts can interrupt system calls, unless an appropriate spinlock is taken, or interrupts are disabled in some other way:

• spin_lock_irq*() gets a spinlock and disables hardware interrupts (and, consequently, also software interrupt and tasklet processing).
• spin_lock_bh() gets a spinlock and disables software interrupt and tasklet processing.
• irq_disable() disables hardware interrupts.
• local_bh_disable() disables software interrupt and tasklet processing.
• preempt_disable() disables preemption, which is also disabled by any of the above.

Now, in non-preemptive kernels, tasks cannot preempt other tasks in kernel mode. So, if you have task A doing some heavy system call on your only CPU, and task B needs to write some data to the audio device, task B may need to wait for task A to end its system call, resulting in dropped audio causing an audible click. Preemptive kernels are for that case.

Comments

[TheMeaningfulEngineer]

One part of the system calls is executed in kernels space. A found the following: However, Linux does not support the most demanding real-time applications because its kernel is nonpreemptive at the end of this chapter http://oreilly.com/catalog/linuxkernel/chapter/ch10.html#947‌​26. Please comment on that

[BitsOfNix]

@Alan you should try to find a more recent book. That one covers kernel 2.2 and at the time 2.4 was coming out. It does not even mention the Completely Fair Scheduler that was introduced in an update of 2.6 and with the latest version 3 there are also big changes regarding preemptive processes under kernel space.

[slm]

@Alan - Alexandre is right. Get more current docs.

[slm]

This might be helpful: makelinux.net/kernel_map. Also there are a number of links to this Q&A I did for JoelDavis a couple of months ago that might be useful: unix.stackexchange.com/questions/76970/…

[TheMeaningfulEngineer]

Shouldn't the preemption of task A come from some form of an interrupt (say an interrupt which is signaling that the device task B has to write to is ready for accepting data) which could preempt the system call task A is undergoing? So it isn't task B which is interrupting directly.

[ninjalj]

Yes. The difference being that after returning from the interrupt, a reschedule may happen immediately, without waiting for the interrupted system call to finish.

[TheMeaningfulEngineer]

Is the possibility to interrupt system calls directly related with the acceptance of the rt_patch in the mainline Linux kernel?

[slm]

@Alan - I would think so. See my updates to my answer.