Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LINUX/BASE] Fixed mmap usage and (re)-implemented most parts of memory_posix.cc #2230

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

guccigang420
Copy link

As the title says. Previously the MapFileView function did not take into account the handle argument, as it used the MAP_ANONYMOUS and the MAP_PRIVATE flags.

Additionally, AllocFixed used mmap and DeallocFixed used munmap always, with the MAP_FIXED flag. This was not ideal for several reasons:

  1. Invoking mmap the way it was invoked silently unmaps the range from the file it was previously mapped to.
  2. MAP_FIXED was used even with a nullptr base_address.
  3. Mapped file memory should not be unmapped in DeallocFixed.

For more information regarding mmap, see:
https://man7.org/linux/man-pages/man2/mmap.2.html

flags |= MAP_FIXED_NOREPLACE;
}
void* result = mmap(base_address, length, prot, flags, -1, 0);

if (result == MAP_FAILED) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally reverse this statement to prevent nesting.

aka.

if (result != MAP_FAILED) {
  return result;
}


<remaining code without else>

if (result == MAP_FAILED) {
// If the address is within this range, the mmap failed because we have
// already mapped this memory.
size_t region_begin = (size_t)base_address;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

constify because why not

size_t region_end = (size_t)base_address + length;
for (const auto mapped_range : mapped_file_ranges) {
// Check if the allocation is within this range...
if (region_begin >= mapped_range.region_begin &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe same thing as above. Reverse this condition and check for less nesting.

When it is outside of region then just return nullptr


int flags = MAP_SHARED;
if (base_address != nullptr) {
flags = flags | MAP_FIXED_NOREPLACE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

flags |= MAP_FIXED_NOREPLACE;


if (result == MAP_FAILED) {
return nullptr;
}else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

else is unnecessary here

@@ -96,6 +127,15 @@ void* AllocFixed(void* base_address, size_t length,

bool DeallocFixed(void* base_address, size_t length,
DeallocationType deallocation_type) {
size_t region_begin = (size_t)base_address;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

constify

@guccigang420
Copy link
Author

So I did implement some of these recommendations. I also added a mutex to avoid race conditions in multi-threaded scenarios.

@guccigang420 guccigang420 force-pushed the mmap-fix branch 3 times, most recently from 1cf68b7 to 3e18402 Compare October 4, 2023 19:12
return munmap(base_address, length) == 0;
default:
assert_unhandled_case(deallocation_type);
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a release build the compiler here complained that there is no return value for all control paths. Just add a return false at the end of the function just to make it happy for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants