This is an archive of the discontinued LLVM Phabricator instance.

[scudo] Secondary allocator overhaul to support Windows
ClosedPublic

Authored by cryptoad on Mar 1 2018, 9:12 AM.

Details

Summary

The need for this change stems from the fact that Windows doesn't support
partial unmapping (MEM_RELEASE implies the entire allocated region). So we
now have to keep track of the reserved region and the committed region, so that
we can function without the trimming we did when dealing with larger alignments.

Instead of just having a ReservedAddressRange per chunk, we introduce a
LargeChunkHeader (and LargeChunk namespace) that additionally holds the
committed size and the usable size. The former is needed for stats purposes,
the latter is used by the frontend. Requiring both is debatable, we could only
work with the usable size but then be off by up to a page per chunk when
dealing with stats.

Additionally, we introduce more stats since they turned out to be useful for
experiments, and a PrintStats function that will be used by the combined
allocator in later patch.

Diff Detail

Event Timeline

cryptoad created this revision.Mar 1 2018, 9:12 AM
Herald added subscribers: Restricted Project, delcypher. · View Herald TranscriptMar 1 2018, 9:12 AM
cryptoad updated this revision to Diff 136551.Mar 1 2018, 9:33 AM

Reordering a couple of lines, adding an UNLIKELY.

Seems sane and I like the fact that it is more uniform now, but need some more time processing it. Meanwhile, since Windows requirements are so different, have you thought about having a separate, Windows-specific secondary allocator?

alekseyshl added inline comments.Mar 2 2018, 3:23 PM
lib/scudo/scudo_allocator_secondary.h
135–138

This is definitely confusing. One getHeader() expects user mem ptr, another expects chunk header ptr. Not sure what's the best way to improve it yet.

cryptoad added inline comments.Mar 5 2018, 8:07 AM
lib/scudo/scudo_allocator_secondary.h
135–138

Initially I was going to add a comment with some chunk layout, eg:

+------------------+
| Guard page(s)    |
+------------------+
| Unused space*    |
+------------------+
| LargeChunkHeader |
+------------------+
| PackedHeader     |
+------------------+
| Data             |
+------------------+
| Unused space**   |
+------------------+
| Guard page(s)    |
+------------------+

The frontend deals with the {Unp,P}ackedHeader, and the Secondary being part of the Backend deals with the LargeChunkHeader.
While I agree that the distinction can be tenuous to make, it makes sense to me that the 2 getHeader work on different pointers.

alekseyshl added inline comments.Mar 5 2018, 10:06 AM
lib/scudo/scudo_allocator_secondary.h
135–138

I would agree with Frontend/Backend separation argument, should this class not be aware of and not use "Chunk::getHeaderSize()".

cryptoad added inline comments.Mar 5 2018, 10:21 AM
lib/scudo/scudo_allocator_secondary.h
135–138

This is indeed the annoying part.
I was thinking about this recently: in the current state of things we need the frontend header size because the user pointer has to be aligned, so we have to know how much space the frontend header is taking. I could pass that header size as ExtraBytes or something to the Secondary that would still do the necessary adjustments.
I don't see a way out without the secondary taking care of it's own alignment needs.

alekseyshl accepted this revision.Mar 8 2018, 1:10 PM
alekseyshl added inline comments.
lib/scudo/scudo_allocator_secondary.h
135–138

Ok, I have no better ideas at the moment. let's add the comment with the chunk alignment graphics and leave it at that.

This revision is now accepted and ready to land.Mar 8 2018, 1:10 PM
cryptoad updated this revision to Diff 137772.Mar 9 2018, 9:06 AM

Added comment with chunk layout.
Moved the LargeChunkHeader inside the LargeChunk namespace as Header,
because it makes more sense to me.

cryptoad marked 5 inline comments as done.Mar 9 2018, 9:07 AM
alekseyshl accepted this revision.Mar 9 2018, 11:19 AM
This revision was automatically updated to reflect the committed changes.