java-topology/defects/ppsspp/patch/ppsspp-0004-kernel-mutex-waitingThreads-dedup.patch
russell@unturf.com 54827d6eb7 ppsspp: add ppsspp-0004 CWE-407 mutex waitingThreads dedup, extend unit test to 8/8 PASS
ppsspp-0004: sceKernelLockMutex/CB and sceKernelLockLwMutex/CB (4 sites)
scan mutex->waitingThreads vector with std::find before push_back --
O(W) per lock attempt. Fix: parallel unordered_set for O(1) dedup.
Unit test extended to cover ppsspp-0004; all 8/8 PASS (ratios 5-27x).
2026-03-31 19:37:31 -04:00

37 lines
2.4 KiB
Diff

--- a/Core/HLE/sceKernelMutex.cpp
+++ b/Core/HLE/sceKernelMutex.cpp
@@ -547,3 +547,3 @@
// May be in a tight loop timing out (where we don't remove from waitingThreads yet), don't want to add duplicates.
- if (std::find(mutex->waitingThreads.begin(), mutex->waitingThreads.end(), threadID) == mutex->waitingThreads.end())
+ if (mutex->waitingThreadSet.insert(threadID).second)
mutex->waitingThreads.push_back(threadID);
@@ -569,3 +569,3 @@
// May be in a tight loop timing out (where we don't remove from waitingThreads yet), don't want to add duplicates.
- if (std::find(mutex->waitingThreads.begin(), mutex->waitingThreads.end(), threadID) == mutex->waitingThreads.end())
+ if (mutex->waitingThreadSet.insert(threadID).second)
mutex->waitingThreads.push_back(threadID);
@@ -950,3 +950,3 @@
// May be in a tight loop timing out (where we don't remove from waitingThreads yet), don't want to add duplicates.
- if (std::find(mutex->waitingThreads.begin(), mutex->waitingThreads.end(), threadID) == mutex->waitingThreads.end())
+ if (mutex->waitingThreadSet.insert(threadID).second)
mutex->waitingThreads.push_back(threadID);
@@ -985,3 +985,3 @@
// May be in a tight loop timing out (where we don't remove from waitingThreads yet), don't want to add duplicates.
- if (std::find(mutex->waitingThreads.begin(), mutex->waitingThreads.end(), threadID) == mutex->waitingThreads.end())
+ if (mutex->waitingThreadSet.insert(threadID).second)
mutex->waitingThreads.push_back(threadID);
#
# CWE-407: sceKernelLockMutex / sceKernelLockMutexCB /
# sceKernelLockLwMutex / sceKernelLockLwMutexCB each scan
# mutex->waitingThreads vector with std::find before push_back —
# O(W) per lock attempt where W = number of waiting threads.
# The code comment says "May be in a tight loop timing out" — that
# tight-loop scenario is exactly where O(W) dedup compounds:
# T attempts * W waiters = O(T*W) total work per timeout cycle.
# Fix: maintain parallel unordered_set<SceUID> waitingThreadSet for
# O(1) dedup; remove from set wherever waitingThreads is cleared/erased.
# Severity: MEDIUM — mutex lock is a hot HLE synchronization path;
# games with thread pools or producer-consumer patterns will trigger
# this on every lock contention timeout cycle.
# Sites: sceKernelLockMutex (line 548), sceKernelLockMutexCB (line 570),
# sceKernelLockLwMutex (line 951), sceKernelLockLwMutexCB (line 986).