为什么getpid被实现为系统调用？

Question

我正在上我的第一堂操作系统课，所以希望我在这里没有任何大的误解。

我想知道为什么getpid（）在Linux中实现为系统调用。据我所知，某些函数被做成系统调用，因为它们访问或更改操作系统可能想要保护的信息，所以它们被实现为系统调用，以便将控制权转移到内核。

但据我所知，getpid（）只是返回调用进程的进程id。是否存在不授予此信息权限的情况？简单地让getpid（）成为一个普通的用户函数不是很安全吗？

谢谢你的帮助。

Answer 1

我认为将pid暴露给进程没有任何安全问题。操作系统强制执行进程地址空间隔离。如果我没记错的话，对getpid（）的第一次调用是一个系统调用，但是以后对getpid（）的调用会被缓存（可能由libc缓存）并在本地处理。

Answer 2

Getpid（）可能只是从一个位置读取，但必须有人写入该位置。为了提供从写入垃圾到操作系统使用的位置的任何旧进程，需要保护它免受用户模式访问。为了让应用程序访问该位置，它需要在内核模式下这样做。因此，它必须作为系统调用完成。

Answer 3

在没有系统调用的情况下实现getpid（）的唯一方法是首先执行一个系统调用并缓存其结果。然后，对getpid（）的每次调用都将返回该缓存值，而无需系统调用。

但是，Linux手册页项目解释了为什么getpid（）没有被缓存：

   From glibc version 2.3.4 up to and including version 2.24, the glibc
   wrapper function for getpid() cached PIDs, with the goal of avoiding
   additional system calls when a process calls getpid() repeatedly.
   Normally this caching was invisible, but its correct operation relied
   on support in the wrapper functions for fork(2), vfork(2), and
   clone(2): if an application bypassed the glibc wrappers for these
   system calls by using syscall(2), then a call to getpid() in the
   child would return the wrong value (to be precise: it would return
   the PID of the parent process).  In addition, there were cases where
   getpid() could return the wrong value even when invoking clone(2) via
   the glibc wrapper function.  (For a discussion of one such case, see
   BUGS in clone(2).)  Furthermore, the complexity of the caching code
   had been the source of a few bugs within glibc over the years.

   Because of the aforementioned problems, since glibc version 2.25, the
   PID cache is removed: calls to getpid() always invoke the actual
   system call, rather than returning a cached value.

总之，如果缓存了getpid（），它可能会返回错误的值（即使缓存在不允许任何程序写入的情况下完成得很好，等等）过去这是一个bug的来源。

通常，您在任何进程中只需要一个getpid（）调用，如果您多次使用结果，请将其保存在变量中（应用程序级缓存！）。

干杯！