Use fallocate on truncate_file #106
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On linux platform, boost interprocess shared memory uses sharder memory files allocated in /dev/shm which is tmpfs. Upon creating a file [1], boost tried to resize it to a requested length [2], through a ftruncate call, whichchanges the size, but does not actually guarantee that the memory will be allocated. As result, when accessing the memory linux kernel will try to allocate it and if the host is under memory pressure the allocation attempt may fail and application will receive a SIGBUS and crash. This change introduces poxis_fallocate call, which guarantees memory to be allocated or otherwise the call will fail. This behavior is easier to handle than recovering after SIGBUS. The fallocate is supported for tmpfs, which is used for /dev/shm since linux 3.5 [3]. For older versions, which do not support fallocate syscall, the glibc will emulate the behavior. [1] https://github.com/boostorg/interprocess/blob/boost-1.68.0/include/boost/interprocess/detail/managed_open_or_create_impl.hpp#L368 [2] https://github.com/boostorg/interprocess/blob/boost-1.68.0/include/boost/interprocess/detail/managed_open_or_create_impl.hpp#L403 [3] https://elixir.bootlin.com/linux/v3.5/source/mm/shmem.c#L2721
|
This will probably fix #114 |
|
Many thanks! I've applied a patch based on your pull request. |
ktf
added a commit
to alisw/boost
that referenced
this pull request
Nov 21, 2023
Previously, ftruncate usage did not actually enforce the memory was actually available. Switching to posix_fallocate (see boostorg/interprocess#106) does so, breaking a few tests and possibly other parts of our stack. Interim solution until we cleanup things or decide on a different strategy.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On linux platform, boost interprocess shared memory uses shared memory files allocated in /dev/shm which is tmpfs. Upon creating a file [1], boost tried to resize it to a requested length [2] through a ftruncate call, which changes the size but does not actually guarantee that the memory will be allocated. As result, when accessing the memory linux kernel will try to allocate it and if the host is under memory pressure, the allocation attempt may fail and application will receive a SIGBUS and crash.
This change introduces posix_fallocate call, which guarantees memory to be allocated or otherwise the call will fail. This behavior is easier to handle than recovering after SIGBUS. The fallocate is supported for tmpfs, which is used for /dev/shm since linux 3.5 [3]. For older versions, which do not support fallocate syscall, the glibc will emulate the behavior.
[1] https://github.com/boostorg/interprocess/blob/boost-1.68.0/include/boost/interprocess/detail/managed_open_or_create_impl.hpp#L368
[2] https://github.com/boostorg/interprocess/blob/boost-1.68.0/include/boost/interprocess/detail/managed_open_or_create_impl.hpp#L403
[3] https://elixir.bootlin.com/linux/v3.5/source/mm/shmem.c#L2721