c - 多线程 mprotect 的行为

Question

为了并发/并行GC，我感兴趣的是 mprotect 系统调用提供的内存顺序保证(即 mprotect 与多线程的行为或 mprotect 的内存模型)。我的问题是(假设没有编译器重新排序或有足够的编译器障碍)

1. 如果线程 1 由于 mprotect 而触发地址段错误线程 2，我能确定一切都发生在线程 2 之前吗？可以在线程 1 的信号处理程序中观察到系统调用段错误？如果在信号中放置一个完整的内存屏障会怎样在线程 1 上执行加载之前处理程序？

2. 如果线程 1 对设置为线程 2 的 PROT_NONE 并且没有触发段错误，这就足够了吗a 发生在两者之间的关系之前。或者换句话说，如果两个线程执行(*ga 以 0 开始，p 是页对齐地址，以只读方式开始)

   // thread 1
   *ga = 1;
   *(volatile int*)p; // no segfault happens
   
   // thread 2
   mprotect(p, 4096, PROT_NONE); // Or replace 4096 by the real userspace-visible page size
   a = *ga;
   

   是否可以保证线程 2 上的 a 将为 1？ (假设没有在线程 1 上观察到段错误并且没有其他代码修改 *ga)

我最感兴趣的是 Linux 行为，尤其是 x86(_64)、arm/aarch64 和 ppc 上的行为，但欢迎访问有关其他 archs/OS 的信息(对于 windows，将 mprotect 替换为 VirtualProtect 或其他名称... .).到目前为止，我在 x64 和 aarch64 Linux 上的测试表明没有违反这些规定，但我不确定我的测试是否具有决定性，或者该行为是否可以长期依赖。

一些搜索表明，mprotect 可能会在删除权限时对所有映射地址的线程发出 TLB shootdown，这可能会提供此处所述的保证(或者换句话说，提供此保证似乎是这种操作的目标)虽然我不清楚 future 内核代码的优化是否会打破这个保证。

引用 LKML post我一周前问过这个问题，但还没有回复......

编辑:澄清问题。我知道 tlb 击落应该提供我正在寻找的保证，但我想知道是否可以依赖这种行为。换句话说，内核发出此类请求的原因是什么，因为如果不是为了提供某种排序保证，则不需要它。

Answer 1

因此，我在此处发帖一天后在机械同情组中提出了这个问题，并得到了 Gil Tene 的答复。在他的允许下，这是我对他的回答的总结。完整线程可用here以防有任何我没有包含的内容不清楚。

对于操作系统的整体行为。

(as in "would be surprising for an OS to not meet):

1. A call to mprotect() is fully ordered with respect to loads and stores that happen before and after the call. This tends to be trivially achieved at the CPU and OS level because mprotect is a system call, which involves a trap, which in turn involves full ordering. [In strange no-ring-transition-implementations (e.g. in-kernel execution, etc.) the protect call would be presumably responsible for emulating this ordering assumption].

2. A call to mprotect will not return before the protection request semantically takes hold everywhere within the process. If the mprotect() call sets a protection that would cause a fault, any operation on any thread that happens after this mprotect() call is required to fault. Similarly, if the mprotect() call sets a protection that would prevent a fault, any operation on any thread that happens after this mprotect() call is required to NOT fault.

这实质上意味着其他线程对受影响页面的内存操作与调用mprotect 的线程同步。更具体地说，可以预期原始问题中提到的两种情况都得到保证。即

1. 如果观察到由于 mprotect 调用导致受影响页面中一个线程的加载错误，则此错误发生在 mprotect() 调用之后，因此能够观察到 mprotect 之前发生的所有内存操作.

2. 如果观察到受影响页面中一个线程上的加载没有错误地阻止 mprotect 调用，则加载发生在 mprotect 调用之前，并且 mprotect 调用和它之后的任何代码都在加载之后，并且将能够观察加载之前发生的任何内存操作。

还有人指出，传递性可能不起作用，即一个线程上的错误加载可能不会在另一个线程上的非错误加载之后。这可能(实际上)是由 tlb 刷新的非原子性引起的，导致不同的线程/cpus 在不同的时间观察访问权限的变化。