[llvm] Work around documented Linux mmap bug. (PR #152595)

[Richard Smith via llvm-commits]

================
@@ -501,8 +501,15 @@ getOpenFileImpl(sys::fs::file_t FD, const Twine &Filename, uint64_t FileSize,
     std::unique_ptr<MB> Result(
         new (NamedBufferAlloc(Filename)) MemoryBufferMMapFile<MB>(
             RequiresNullTerminator, FD, MapSize, Offset, EC));
-    if (!EC)
-      return std::move(Result);
+    if (!EC) {
+#ifdef __linux__
----------------
zygoloid wrote:

I expect that on any OS, if another process concurrently `mmap`s the file with `MAP_SHARED` and writes into the slack bytes, or truncates the file, we will probably crash, but Linux is the only OS that I've found that documents that this can happen even if the file is not concurrently modified. I wouldn't say I'm sure that other OSes don't have similar behavior; maybe they just don't document it?

I'm happy to generalize the check if you think it's worthwhile; as far as I can see, the only real consequence is that this would fault in the final page earlier, which is probably not an especially interesting difference given that we're presumably going to reach it pretty soon anyway.

https://github.com/llvm/llvm-project/pull/152595