未定义为异步安全的函数（例如 mmap(2)）是否会影响信号处理程序中调用的其他异步安全函数？答案

【问题标题】：Do functions which are not defined as async-safe, such as mmap(2), effect other async-safe functions called in signal handler?未定义为异步安全的函数（例如 mmap(2)）是否会影响信号处理程序中调用的其他异步安全函数？
【发布时间】：2019-05-24 22:02:13
【问题描述】：

我正在创建一个库，它被注入进程并重新定义一些函数，例如 open(2)，以便在调用真正的 open(2) 之前执行一些任务。我的图书馆会调用 mmap(2)。由于 open(2) 是异步安全的，是否有人使用在信号处理程序中调用 open(2) 并且我的库还添加了对 mmap(2) 的调用的库的人可能会使他对 open(2) 的调用出错?

更新问题：

void handle_sigint(int sig)
{
    int fd = open(“file”, O_RDWR, 0666);
    void *base = mmap(NULL, 20, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
}

在上面的函数中，对open(2)的调用会不会因为我调用了mmap(2)而生效？

【问题讨论】：

标签： c signal-handling async-safe

【解决方案1】：

是的。

如果您的替代 open() 调用了一个非异步信号安全的函数，那么信号处理程序调用您的函数是不安全的。它与是异步信号安全的标准函数具有相同的名称和签名是无关紧要的。它调用被替换的函数或其他异步信号安全函数是无关紧要的。预期信号处理程序对非异步信号安全的函数的调用不会是直接，这无关紧要。

针对问题更新：如果问题中提供的函数被调用为信号处理程序，则由于调用mmap()，它具有未定义的行为。该UB的细节无法预测，至少不能从相关标准中预测。这就是“未定义”的意思。没有任何理由假设open() 调用的实际和明显影响会以某种方式受到保护而不受干扰。也不是一般的信号处理机制。程序中也没有其他任何内容。

您离 UB 的位置越远，任何明显影响的可能性就越小，操作系统就越有可能包含它，但 UB 不是什么好东西。原则上，它可能表现为您计算机能力范围内的任何行为或行为，例如擦除磁盘、关闭 CPU 风扇或将密码邮寄给黑客。

【讨论】：

我还有一些疑问，我正在更新问题，也请注意。
@Mihir，我已经更新了我的答案，但请不要再这样做了。在你已经有了答案之后再修改一个问题是不受欢迎的。
知道了，下次记得。

【解决方案2】：

完全有可能。另一个冲突是在 main 上运行的 mmap() 被 sighandler 中断，该 sighandler 调用 open()，后者调用 mmap() 导致 mmap() 重新进入。

这里的大关键字是“可重入”：您在 sighandler 中使用的任何函数都必须是可重入的。这意味着，该函数只操作堆栈数据，或者，如果它操作全局数据或状态，它必须以原子方式进行。原子性是一个非常困难的成就，它伴随着更可怕的副作用，必须处理（即死锁，需要回滚/重启行为......如果你有任何 RDB 经验，你应该知道）。在这种情况下，mmap() 是麻烦的源头，因为它不仅操作进程静态数据，而且跨进程静态数据。

【讨论】：