constexpr-ing.

Passing ReleaseToOsInterval from init to initLinkerInitialized in
the Secondary.

Marking a parameter unused.

Commenting getNumberOfCPUs to indicate failure value in common.h,
moving sched_getaffinity comment in linux.cpp in body of function.

LGTM, Thanks for all the work Peter!

I think this looks good. I think this might not be Fuchsia compatible and could probably use some #if SCUDO_LINUX or ANDROID or top of the __aarch64__ checks.
Fuchsia will want memory tagging support at some point, I 'll check the patch on the platform once the inconsistencies I saw are addressed.

Disable GWP-ASan, FIXME added.

Rebasing.

Adding a newline at end of file, to try and trigger presubmit.

Re-enable GWP-ASan, add a comment about the potentially failing test.
We will skip it if this occurs upstream.

Remove the NOINLINE for enable & disable, they were used to debug
some deadlocks.

I apologize for being pushy, but could I get a yay or nay on this to unblock Android?
Thanks!

Applying simplification suggested by eugenis@: malloc_disable just
calls disable, same for enable.

In D72470#1814446, @eugenis wrote:

SCUDO_PREFIX(Mutex) can be acquired in the child process, and in the parent process, and is not held during fork. That's a potential deadlock.
The condvar code reduces the window for it, but does not eliminate it completely.
Why can't malloc_disable() simply directly call allocator.disable(), and the same in malloc_enable?

Adding a disable()/fork()/enable() test.

Disable GWP-ASan for now.

Wrong version of the makefiles.

Correct several inconsistencies wrt locking orders.

Adding Quarantine & ByteMap to the things we disable/enable.

Corrections.

Abandoning this one, this will come back in another form.

I realized that this is now no longer correct as the atfork handler is only installed in a disable.

Submitting this new design for consideration. I am working on adding
some tests but at least the code idea can get some feedback.

In D72364#1810649, @eugenis wrote:

Right, but it looks like it will have the same effect.
Attempting to disable an already disabled allocator will block until the allocator is enabled.
I.e. pthread_atfork(disable, enable, enable) should be sufficient.

In D72364#1810596, @eugenis wrote:

I see. I think the other approach could be safer. Grab all the locks before fork and release them after fork. This will also allow user applications to use malloc after fork, which ex. glibc allocator supports.

In D72364#1810436, @eugenis wrote:

Could we do this exact same thing in Android? I find this behavior (auto-enabling the allocator after fork) unexpected, and it makes the interface even more confusing then it is now.

Updating test to exercise both disable and no-disable pre-fork.
Added an _exit in fork child.

The wrong version was uploaded.

Correcting comment typo.

New proposal as per Peter's suggestion: include stdint.h in
platform.h and check for __BIONIC__.

Add a comment for disable() with a TODO to improve the behavior.

Use an atomic_u8 for Disabled in the Exclusive Registry.
This should ensure that changes to the variable are visible to the
threads in a somewhat timely manner.

Extra whiteline.

Thanks!
What's the current plan for testing? (Currently I have only enabled the standalone on Linux x86/64 for upstream)

Thanks!

Could you please put a comment somewhere on how to use the benchmark?

In D70762#1767420, @pcc wrote:

When you say reclaiming you mean calling releasePagesToOS(), correct? In that case, wouldn't that cause the header to be set to 0, which would put us in the same state as if we hadn't used the chunk before?

In D70762#1762390, @pcc wrote:

There is already a header field 'SizeOrUnusedBytes" that stores the allocation size. When a chunk is freed, we don't disturb that field. That gives us a way to recover the size of the previous allocation. We can call getChunkFromBlock() (modifying it to accept deallocated chunks) to recover the location of the chunk header given a block.

I think we can use the header itself to store the "has never been tagged" state. If the header read as a word is equal to 0, that means that the chunk has never been used before and we need to IRG before setting tags. That won't result in early paging because by the time we read the header we've already decided to use that block for the allocation.

One complication is that we need to handle the case where the new allocation has lower alignment than the old allocation. In that case, malloc will need to set tags on both sides of the allocation (because the previous free will have retagged starting from a higher address).

Adding a comment saying that a corrupted chunk won't be reported
as owned (well technically it might be "owned"), but that it's WAI.

Adding a log for the new static_assert.

In D70908#1765712, @hctim wrote:

So the model presented asserts that if the chunk header is truncated, the pointer is not owned by us. Is this WAI? I can forsee that a chunk header was truncated, and then the pointer to the associated allocation is checked for ownership, which the ownership will fail as the chunk header check didn't succeed.

In D70860#1764188, @alex wrote:

FYI, I'm not an LLVM committer, so I'll need someone to merge this for me. Thanks!

In D64457#1762220, @hctim wrote:

In D64457#1762210, @cryptoad wrote:

Can this be abandoned? Looks stale.

I'll need to take a look and rethink this - is planned changes okay to get it off your dashboard?

Can this be abandoned? Looks stale.