[PATCH] D58184: [scudo][standalone] Introduce platform specific code & mutexes
Matt Morehouse via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 15 16:33:47 PST 2019
morehouse added inline comments.
================
Comment at: lib/scudo/standalone/common.h:89
+
+template <typename T> INLINE void shuffle(T *A, u32 N, u32 *RandState) {
+ if (N <= 1)
----------------
What is this used for?
================
Comment at: lib/scudo/standalone/common.h:122
+ return PageSizeCached;
+ return getPageSizeSlow();
+}
----------------
If we will always get the page size through this function call (and not the global variable), this could be simplified to:
```
static PageSizeCached = getPageSizeSlow();
return PageSizeCached;
```
================
Comment at: lib/scudo/standalone/common.h:171
+
+extern "C" typedef void (*IterateCb)(uintptr_t Base, size_t Size, void *Arg);
+
----------------
What's this here for?
================
Comment at: lib/scudo/standalone/linux.cc:49
+ if (Flags & MAP_NOACCESS)
+ MmapFlags |= MAP_NORESERVE;
+ if (Addr) {
----------------
Since we will be mapping `PROT_NONE` in the scenario, I believe `MAP_NORESERVE` is unnecessary. I.e., the OS won't reserve swap space anyway since the memory cannot be accessed.
================
Comment at: lib/scudo/standalone/linux.cc:53
+ DCHECK_EQ(Flags & MAP_NOACCESS, 0);
+ MmapFlags |= MAP_FIXED;
+ }
----------------
Does Scudo actually do `MAP_FIXED`? If so, why?
================
Comment at: lib/scudo/standalone/linux.cc:58
+ void *P = mmap(Addr, Size, MmapProt, MmapFlags, -1, 0);
+ if (UNLIKELY(P == MAP_FAILED)) {
+ if (!(Flags & MAP_ALLOWNOMEM) || errno != ENOMEM)
----------------
Considering we just did a system call, this path optimization doesn't provide any substantial benefit.
================
Comment at: lib/scudo/standalone/linux.cc:71
+void unmap(void *Addr, uptr Size, UNUSED uptr Flags, UNUSED u64 *Extra) {
+ if (UNLIKELY(munmap(Addr, Size) != 0))
+ dieOnMapUnmapError();
----------------
Another unnecessary path optimization.
================
Comment at: lib/scudo/standalone/linux.cc:77
+ UNUSED u64 *Extra) {
+ madvise(reinterpret_cast<void *>(BaseAddress + Offset), Size, MADV_DONTNEED);
+}
----------------
Should we check errno for `EAGAIN` here?
================
Comment at: lib/scudo/standalone/linux.cc:84
+void BlockingMutex::wait() {
+ syscall(SYS_futex, (uptr)OpaqueStorage, FUTEX_WAIT_PRIVATE, MtxSleeping,
+ nullptr, nullptr, 0);
----------------
`reinterpret_cast`? Here and below
================
Comment at: lib/scudo/standalone/linux.cc:103
+ CHECK_EQ(sched_getaffinity(0, sizeof(cpu_set_t), &CPUs), 0);
+ return static_cast<u32>(CPU_COUNT(&CPUs));
+}
----------------
Should this be cached, as it is in sanitizer_common?
================
Comment at: lib/scudo/standalone/linux.cc:118
+ syscall(SYS_getrandom, Buffer, Length, Blocking ? 0 : GRND_NONBLOCK);
+ if (ReadBytes == (ssize_t)Length)
+ return true;
----------------
`static_cast`? Same for below.
================
Comment at: lib/scudo/standalone/linux.h:55
+// store sanitizer thread specific data.
+static const int TLS_SLOT_SANITIZER = 8; // TODO(kostyak): 6 for Q!!
+
----------------
Why is this 8 when sanitizer_common uses 6?
================
Comment at: lib/scudo/standalone/mutex.h:39
+ void NOINLINE lockSlow() {
+ for (u8 I = 0;; I++) {
+ if (I < 10)
----------------
With a `u8`, we might wraparound and do 10 more "quick yields" on a long lock. Should we bump this up to `u32` to reduce chance of this happening?
================
Comment at: lib/scudo/standalone/mutex.h:57
+ SpinMutex(const SpinMutex &);
+ void operator=(const SpinMutex &);
+};
----------------
Are these constructors ever used? If not, maybe just use `SpinMutex(const SpinMutex &) = delete`.
================
Comment at: lib/scudo/standalone/mutex.h:100
+ GenericScopedLock(const GenericScopedLock &);
+ void operator=(const GenericScopedLock &);
+};
----------------
Maybe make these deleted too.
Repository:
rCRT Compiler Runtime
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D58184/new/
https://reviews.llvm.org/D58184
More information about the llvm-commits
mailing list