This is an archive of the discontinued LLVM Phabricator instance.

Update sanitizer_allocator to use new API.
ClosedPublic

Authored by flowerhack on Oct 5 2017, 12:25 PM.

Details

Summary

Update sanitizer_allocator to use new API.

Second patch in a series. First patch https://reviews.llvm.org/D39072

Updates MmapNoAccess / MmapFixed call sites in the saniziter_allocator
to use the new Init/Map APIs instead.

Diff Detail

Event Timeline

flowerhack created this revision.Oct 5 2017, 12:25 PM

Mostly LGTM

compiler-rt/lib/sanitizer_common/sanitizer_allocator_primary64.h
78 ↗(On Diff #117864)

This one should pass the name too.

541 ↗(On Diff #117864)

This should be static const char kAllocatorName[], or just drop it and use a string constant at the call site.

flowerhack retitled this revision from DO NOT MERGE, WIP: Update sanitizer_allocator to use new API. to Update sanitizer_allocator to use new API..
flowerhack edited the summary of this revision. (Show Details)
alekseyshl added inline comments.Oct 24 2017, 11:12 AM
lib/sanitizer_common/sanitizer_allocator_primary64.h
630

It should be:

uptr mapped = address_range.Map(beg, size, true /*tolerate_enomem*/);

which got me thinking, to avoid errors like this, maybe it's not that a bad idea to have two members instead of a default parameter:

uptr Map(uptr fixed_addr, uptr size);
uptr MapOrDie(uptr fixed_addr, uptr size);

indeed, we should rename Unmap to UnmapOrDie in this case.

On the other hand, this is the only use of tolerate_enomem, if we get it right right now, I think we'll be fine with the current API.

645

address_range.Unmap(beg, size)

flowerhack marked 2 inline comments as done.
flowerhack added inline comments.
lib/sanitizer_common/sanitizer_allocator_primary64.h
630

fixed

alekseyshl added inline comments.Oct 25 2017, 3:37 PM
lib/sanitizer_common/sanitizer_fuchsia.cc
274

Move it above Unmap

lib/sanitizer_common/sanitizer_win.cc
246

Why do we need MapImpl, why not just inline MapFixed... calls? Same question for other platforms.

flowerhack marked 3 inline comments as done.
flowerhack added inline comments.
lib/sanitizer_common/sanitizer_win.cc
246

good point, done

alekseyshl accepted this revision.Oct 26 2017, 11:02 AM
This revision is now accepted and ready to land.Oct 26 2017, 11:02 AM

Thanks @alekseyshl !

However, https://reviews.llvm.org/D39072 needs to land before this one can be merged. Have you had a chance to look at that one yet? Thanks!

alekseyshl accepted this revision.Oct 31 2017, 3:12 PM
cryptoad requested changes to this revision.Nov 1 2017, 9:44 AM

I have some local tests failure with this patch. Looking into it, do not submit.

lib/sanitizer_common/sanitizer_fuchsia.cc
268

Remove the 2 extra empty lines.

This revision now requires changes to proceed.Nov 1 2017, 9:44 AM

SanitizerCommon-tsan-x86_64-Linux :: Linux/decorate_proc_maps.cc appears to consistently fail with that patch.
With error message: ==14973==FATAL: ThreadSanitizer: failed to intercept open

This is due to decorate_proc_maps.
From Initialize, tsan's Init calls InitializeAllocator, which ends up calling MmapFixedNoAccess.
name is not null, so it continues to GetNamedMappingFd, which itself calls shm_open, which calls the open interceptor, and it all dies.

So this could go away with AllocatorName returning null, but it's not an actual fix, we would just be pretending the issue is not there.
Adding @dvyukov for input.

So to be clearer, this is a problem for every sanitizer intercepting open and using a map with a name and decorate_proc_maps=1 during the init.
esan seems to be the only other (than tsan) that does that. So when running the libc-intercept.c test case with decorate_proc_maps=1, it also segfaults.

dvyukov edited edge metadata.Nov 3 2017, 3:29 AM

So this could go away with AllocatorName returning null, but it's not an actual fix, we would just be pretending the issue is not there.
Adding @dvyukov for input.

I don't fully understand what's the problem. Aleksey, can you please help with this?

flowerhack updated this revision to Diff 121548.Nov 3 2017, 2:16 PM
flowerhack edited edge metadata.
flowerhack marked an inline comment as done.

The root bug is that, if you have decorate_proc_maps enabled, *and* actually use a named mapping, *and* are using a sanitizer intercepting open (just TSAN and ESAN), then we'll get an explosion during initialization.

I've updated this CL with what seems like a reasonable fix to me: change ReservedAddressRange::Init to not use name on POSIX, since that's where the problem happens (Fuchsia is fine with names).

I can file a bug for allowing named mappings can be used everywhere more easily (the fix may involve e.g. porting shm_open s.t. it's not invoking open, which is what's causing the problem), if that's desired?

Please let me know if this minor change is satisfactory so I can go ahead with it, thanks~

flowerhack updated this revision to Diff 121551.Nov 3 2017, 2:17 PM
alekseyshl accepted this revision.Nov 3 2017, 5:07 PM

The root bug is that, if you have decorate_proc_maps enabled, *and* actually use a named mapping, *and* are using a sanitizer intercepting open (just TSAN and ESAN), then we'll get an explosion during initialization.

I've updated this CL with what seems like a reasonable fix to me: change ReservedAddressRange::Init to not use name on POSIX, since that's where the problem happens (Fuchsia is fine with names).

I can file a bug for allowing named mappings can be used everywhere more easily (the fix may involve e.g. porting shm_open s.t. it's not invoking open, which is what's causing the problem), if that's desired?

Please let me know if this minor change is satisfactory so I can go ahead with it, thanks~

Looks like a perfectly acceptable fix to me, we never named these mappings. Please add a comment with TODO there explaining why we're not passing name down (pretty much what cryptoad@ said).

flowerhack updated this revision to Diff 121790.Nov 6 2017, 2:35 PM
cryptoad accepted this revision.Nov 6 2017, 3:17 PM
cryptoad added inline comments.
lib/sanitizer_common/sanitizer_posix_libcdep.cc
346

I think you can skip the possible solution part.
If not, at least s/ccomplain/complain/ :)

This revision is now accepted and ready to land.Nov 6 2017, 3:17 PM
flowerhack updated this revision to Diff 121820.Nov 6 2017, 5:10 PM
flowerhack marked an inline comment as done.
cryptoad closed this revision.Nov 7 2017, 8:19 AM