System calls quizz

  1. What is special about the socket, connect, bind, accept, … system calls?
  2. How does the errno value get from the kernel to applications?
  3. Some system calls return a number of times different of 1 in some cases. Which ones? (Put differently: enter a syscall once, exit more or less than once. Which ones can do that?)

(Thanks MG!)

5 thoughts on “System calls quizz

  1. 1) They go through socketcall() on linux (ok, I had to google this one)
    2) syscall returns a negative number which glibc puts into errno (as a positive number)
    3) fork (2) exec (0) exit (0)

  2. 1) All of them get called through a multiplexed system call, at least on the most common architectures.
    2) Any return value from *any* syscall that falls between -1 and -4095 will become an errno value. No syscall may return a legitimate value in that range.
    3) By design: fork, vfork, clone (the underlying syscall, not the library function), execve, exit, exit_group. Also, reboot will not return before rebooting. :) A call to kill/tkill/tgkill that targets the calling process must deliver the self-signal before returning, so if you kill self (or the process group containing self) with SIGKILL, the syscall won’t return. Also, the “write” syscall on various sysfs, proc, or device might trigger an action that kills the process or the system. :) AppArmor, in particular, has a “magic cookie” mechanism used to put on various security “hats”, and if you write the wrong cookie value your process gets unceremoniously killed. And, technically, a handful of other syscalls can also cause the process to never return from the kernel due to blocking forever, and of course any syscall can fail to return if you kill the process/thread from some other process/thread.

  3. Followup on 1: on some architectures, specifically those where the syscalls previously existed independently of the multiplexing syscall, those legacy versions also exist and call the same internal kernel implementation.

Comments are closed.