-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix: Proper handling of system shm register offset #8330
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes a bug in shared memory handling where the register offset was being applied twice during memory mapping operations, leading to out-of-bounds read issues. The fix ensures that when mmap returns a starting address that already includes the register offset, the offset is not added again during memory access.
Key changes:
- Removes duplicate register offset calculation in the C++ shared memory manager
- Updates test utilities to properly handle register offsets for different memory types
- Adds comprehensive tests for large shared memory register offsets across multiple backend types
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/shared_memory_manager.cc | Removes duplicate register offset calculation for CPU memory types |
| qa/common/infer_util.py | Updates test utility to handle register offsets and support multiple model backends |
| qa/L0_shared_memory/test.sh | Adds test infrastructure for large shared memory register offset testing |
| qa/L0_shared_memory/shared_memory_test.py | Implements comprehensive test for large register offsets across backend types |
| *shm_info = std::static_pointer_cast<const SharedMemoryInfo>(it->second); | ||
| } | ||
|
|
||
| if (it->second->kind_ == TRITONSERVER_MEMORY_CPU) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
System shm is treated differently from CUDA shm. mmap returns the address starting at the offset. Therefore no need to add another offset to it.
What does the PR do?
When calling
mmapsystem call, the returned starting address is starting at the shm register offset (must be multiples of page size) already. Later the register offset is added to the starting address again and raises out-of-bound write issue.Checklist
<commit_type>: <Title>Commit Type:
Check the conventional commit type
box here and add the label to the github PR.
Related PRs:
Where should the reviewer start?
Test plan:
L0_shared_memory
L0_cuda_shared_memory
32791300
Caveats:
Background
https://man7.org/linux/man-pages/man2/mmap.2.html
Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)