Possible data race in the iteration of Stack's pop and UnionNode
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- distributed-systems
Research direction
Start with the linked src/pool/treiber/llsc.rs lines 84-116 and compare the corresponding CAS implementation, focusing on the head load and next-pointer read described in the report. Use loom and miri to reproduce or validate the suspected race; done means the iteration is race-free without an unresolved memory-safety regression.
Written by the indexing model from the issue text.
Description
I will use the code from the LL-SC implementation, but the same applies to the CAS one.
Between the head load in line 89 and the read to get the next pointer in line 95, another thread could have started and successfully finished a try_pop. Back to the first thread, now the top points to an in-use node that can be written to, since the storage for the next pointer and the data are the same (i.e. it's an union) we now get a data race.
I will try to trigger it with loom and miri and then try to come up with a fix. The simplest solution seems to replace the UnionNode with StructNode. However, I hope I can find a solution that doesn't incur in more memory usage, specially since I was the one that came up with the union suggestion years ago...
- Dominant language
- Rust
- Stars
- 2k
- Forks
- 253
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-embedded/heapless
-
`FromIterator` for `Deque`Possibly taken @ollien claimed this 60 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
rust-embedded/heapless#683 ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
rust-embedded/heapless#681 ·
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 55/100
rust-embedded/heapless#653 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 28/100
rust-embedded/heapless#645 · 5 comments · 1 reaction ·
-
Vec const-nessOpen
Difficulty 3/5 1-2 days Newbie friendliness 45/100
rust-embedded/heapless#643 · 3 comments ·
All issues in rust-embedded/heapless
Similar issues
-
[Feature] 设置里面的同步功能Openenhancement user-priority/P2
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
agent:triaged bug bughunt pm:npm priority:p1
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
SocketDev/socket-patch#1127 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day