aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/StringRef.cpp
diff options
context:
space:
mode:
authorDmitry Vyukov <dvyukov@google.com>2021-12-02 13:35:04 +0100
committerDmitry Vyukov <dvyukov@google.com>2021-12-02 17:50:51 +0100
commit1b576585eba4d08d5c97c39f5f43d0bf6eed4e4e (patch)
tree616587be7bd2444743b0098bed4b71bf01c68c6d /llvm/lib/Support/StringRef.cpp
parent92fbd76af525095197188c862db2c4f5b96a8a73 (diff)
downloadllvm-1b576585eba4d08d5c97c39f5f43d0bf6eed4e4e.zip
llvm-1b576585eba4d08d5c97c39f5f43d0bf6eed4e4e.tar.gz
llvm-1b576585eba4d08d5c97c39f5f43d0bf6eed4e4e.tar.bz2
tsan: tolerate munmap with invalid arguments
We call UnmapShadow before the actual munmap, at that point we don't yet know if the provided address/size are sane. We can't call UnmapShadow after the actual munmap becuase at that point the memory range can already be reused for something else, so we can't rely on the munmap return value to understand is the values are sane. While calling munmap with insane values (non-canonical address, negative size, etc) is an error, the kernel won't crash. We must also try to not crash as the failure mode is very confusing (paging fault inside of the runtime on some derived shadow address). Such invalid arguments are observed on Chromium tests: https://bugs.chromium.org/p/chromium/issues/detail?id=1275581 Reviewed By: melver Differential Revision: https://reviews.llvm.org/D114944
Diffstat (limited to 'llvm/lib/Support/StringRef.cpp')
0 files changed, 0 insertions, 0 deletions