Skip to content

Conversation

@adamsitnik
Copy link
Member

@adamsitnik adamsitnik commented Jan 25, 2022

A manual backport of #64099

The sys-call that we use to create shared memory mapped objects (shm_open) has distro-specific map name length requirements. On most Unix-like Operating Systems it's PATH_MAX (4096), while on macOS it's SHM_NAME_MAX which for the arm64 version currently maps to 32. The code has been simply generating a string that is too long.

Customer Impact

Customer reported #63240 in 6.0. macOS arm64 users can't create a memory mapped file which is not backed by a real file (MemoryMappedFile.CreateNew(mapName: null)) . There is no workaround.

Testing

The tests have been.. re-enabled. Yes, we had failing tests that were clearly saying that there is a bug but they got disabled rather than fixed.

Risk

Low. By reducing the map name length we have reduced the entropy so chances for generating a name that is already in use have increased. However, a simple retry logic was added and it ensures that even if a shared map object with a given name already exists, a new name is generated and the process is repeated until it succeeds (or fails for other reasons).

dotnet#64099)

Co-authored-by: Stephen Toub <stoub@microsoft.com>
# Conflicts:
#	src/libraries/System.IO.MemoryMappedFiles/tests/MemoryMappedFile.CreateNew.Tests.cs
#	src/libraries/System.IO.MemoryMappedFiles/tests/MemoryMappedViewAccessor.Tests.cs
#	src/libraries/System.IO.MemoryMappedFiles/tests/MemoryMappedViewStream.Tests.cs
#	src/libraries/System.IO.MemoryMappedFiles/tests/MemoryMappedViewStreamConformanceTests.cs
@ghost
Copy link

ghost commented Jan 25, 2022

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

Issue Details

A manual backport of #64099

Author: adamsitnik
Assignees: -
Labels:

area-System.IO

Milestone: -

@ghost ghost assigned adamsitnik Jan 25, 2022
@adamsitnik
Copy link
Member Author

/azp run runtime-extra-platforms

@azure-pipelines
Copy link

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

return null;
}
Interop.ErrorInfo errorInfo = Interop.Sys.GetLastErrorInfo();
fd.Dispose();
Copy link
Member

Choose a reason for hiding this comment

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

FWIW, it's a little weird to Dispose of the SafeHandle and then continue to use it, but technically in this case it's ok to do so, given how it's being used. It's just unusual to see and thus a little disconcerting.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe a comment here would help clarify the unusual usage?

@danmoseley
Copy link
Member

Could you add a template we could review, before tactics mail?

@adamsitnik adamsitnik added the Servicing-consider Issue for next servicing release review label Jan 25, 2022
@adamsitnik
Copy link
Member Author

Could you add a template we could review, before tactics mail?

Done

@danmoseley
Copy link
Member

Template looks good. I added that its customer reported. Feel free to send mail..

@leecow leecow added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jan 25, 2022
@leecow leecow added this to the 6.0.3 milestone Jan 25, 2022
@safern safern merged commit 2168e52 into dotnet:release/6.0 Feb 7, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Mar 10, 2022
@adamsitnik adamsitnik deleted the backportMemoryMappedFilesFix branch June 23, 2022 07:14
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-System.IO Servicing-approved Approved for servicing release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants