This is an archive of the discontinued LLVM Phabricator instance.

[scudo][standalone] Correct min/max region indices
ClosedPublic

Authored by cryptoad on Nov 9 2020, 3:15 PM.

Details

Summary

The original code to keep track of the minimum and maximum indices
of allocated 32-bit primary regions was sketchy at best.

MinRegionIndex & MaxRegionIndex were shared between all size
classes, and could (theoretically) have been updated concurrently. This
didn't materialize anywhere I could see, but still it's not proper.

This changes those min/max indices by making them class specific rather
than global: classes are locked when growing, so there is no
concurrency there. This also allows to simplify some of the 32-bit
release code, that now doesn't have to go through all the regions to
get the proper min/max. Iterate and unmap will no longer have access to
the global min/max, but they aren't used as much so this is fine.

Diff Detail

Event Timeline

cryptoad created this revision.Nov 9 2020, 3:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 9 2020, 3:15 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
cryptoad requested review of this revision.Nov 9 2020, 3:15 PM
cryptoad updated this revision to Diff 304220.Nov 10 2020, 8:56 AM

Further simplify the release function.

Ping please!

hctim accepted this revision.Nov 13 2020, 12:55 PM

LGTM w/ nits

compiler-rt/lib/scudo/standalone/primary32.h
169

If it's substantially cheaper to walk each class and get the region bounds, can you do the same thing for unmapTestOnly? If it's not a whole bunch cheaper, can you change this to just walk all the regions?

307

Instead of rematerializing, can you pass the size class info as a parameter from populateFreeList.

321

Probably didn't help because of the rematerialization, but can you add a comment here that Sci->Mutex is already locked by the caller?

This revision is now accepted and ready to land.Nov 13 2020, 12:55 PM

Before submitting, this seems to have some performance issues. I see some cases where it's much better, but I see a lot of cases where it's much slower.

I'll put the list of the worst offenders and I need to dig to see if the data is good.

Okay, every calloc/malloc seems to be much slower. I'm going to rerun because it doesn't seem like this change should be causing this kind of problem.

cryptoad updated this revision to Diff 305323.Nov 14 2020, 10:45 AM
cryptoad marked 3 inline comments as done.

Addressing review comments.

cferris accepted this revision.Nov 16 2020, 10:57 AM

Ignore the performance drop, it looks like something else introduced a regression that I need to track down. This change doesn't change performance in any measurable way.

This revision was automatically updated to reflect the committed changes.