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

check the right return value for mmap #77952

Merged
merged 1 commit into from
Nov 7, 2022
Merged

check the right return value for mmap #77952

merged 1 commit into from
Nov 7, 2022

Conversation

mangod9
Copy link
Member

@mangod9 mangod9 commented Nov 6, 2022

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

@ghost
Copy link

ghost commented Nov 6, 2022

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

FIxes: #77477. mmap returns MAP_FAILED rather than NULL on failures.

Author: mangod9
Assignees: mangod9
Labels:

area-GC-coreclr

Milestone: -

@mangod9
Copy link
Member Author

mangod9 commented Nov 7, 2022

the failures are all helix timeouts. But the musl arm outerloop failure is fixed after this change.

@stephentoub
Copy link
Member

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

@mangod9
Copy link
Member Author

mangod9 commented Nov 7, 2022

We have some other usage of mmap, e.g. as part of MemoryMappedFiles. Do we need to fix anything there?

I can take a look, but assuming its been that way for a while? This particular code was recently added to coreclr (was only included within standalone GC previously), hence we are noticing this issue now.

@mangod9
Copy link
Member Author

mangod9 commented Nov 7, 2022

mmap return value is handled correctly here:

// NOTE: Shim returns null pointer on failure, not non-null MAP_FAILED sentinel.

Copy link
Member

@janvorli janvorli left a comment

Choose a reason for hiding this comment

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

LGTM. Thank you!

@mangod9 mangod9 merged commit 892ebf4 into dotnet:main Nov 7, 2022
@mangod9 mangod9 deleted the fix_arm branch November 7, 2022 14:44
@stephentoub
Copy link
Member

mmap return value is handled correctly here:

Is it? SystemNative_MMap is just coercing MMAP_FAILED into NULL:

if (ret == MAP_FAILED)
{
return NULL;
}

But my understanding from this PR is that mmap returning NULL is actually a success case, not failure, and SystemNative_MMap is conflating the two such that
if (addr == IntPtr.Zero) // note that shim uses null pointer, not non-null MAP_FAILED sentinel
{
throw Interop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo());
}
then treats both as failure.

Do we know in what situations null might be returned as a success case?

@jkotas
Copy link
Member

jkotas commented Nov 7, 2022

We know in what situations null might be returned as a success case?

When you map a page at address 0 (some Unix versions allow that). CoreCLR does not support that configuration.

@stephentoub
Copy link
Member

When you map a page at address 0

Ok, thanks.

CoreCLR does not support that configuration.

Does mono?

@janvorli
Copy link
Member

janvorli commented Nov 7, 2022

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

When MAP_FIXED is not set, the implementation uses addr in an implementation-defined manner to arrive at pa. The pa so chosen shall be an area of the address space that the implementation deems suitable for a mapping of len bytes to the file. All implementations interpret an addr value of 0 as granting the implementation complete freedom in selecting pa, subject to constraints described below. A non-zero value of addr is taken to be a suggestion of a process address near which the mapping should be placed. When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.

@stephentoub
Copy link
Member

Actually, mmap is not allowed to return NULL by spec unless MAP_FIXED is passed to it.

Perfect. Thanks.

mangod9 added a commit to mangod9/runtime that referenced this pull request Nov 10, 2022
mangod9 added a commit to mangod9/runtime that referenced this pull request Nov 24, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Test failure GC/LargeMemory/Regressions/largearraytest/largearraytest.sh
4 participants