java-topology/defects/ppsspp/patch/ppsspp-0002-kernel-semaphore-waitingThreads-dedup.patch

17 lines
882 B
Diff

# UNDF: UNDF-2026-000000902
--- a/Core/HLE/sceKernelSemaphore.cpp
+++ b/Core/HLE/sceKernelSemaphore.cpp
@@ -370 +370 @@
- if (std::find(s->waitingThreads.begin(), s->waitingThreads.end(), threadID) == s->waitingThreads.end())
+ if (s->waitingThreadSet.insert(threadID).second)
s->waitingThreads.push_back(threadID);
#
# CWE-407: sceKernelWaitSemaCB / sceKernelWaitSema scan
# s->waitingThreads vector with std::find before push_back — O(W)
# per sema wait. Comment in code says "May be in a tight loop timing
# out (where we don't remove from waitingThreads yet), don't want to
# add duplicates." — the tight-loop scenario is exactly where O(W)
# dedup costs compound.
# Fix: maintain parallel unordered_set for O(1) dedup.
# Severity: MEDIUM — semaphore wait is a critical HLE synchronization
# primitive; games using producer-consumer patterns hit this frequently.