Skip to content

QReadWriteLock: fix 3 data races

Andreas Sturmlechner requested to merge asturmlechner/qtbase:QReadWriteLock-data-races into kde/5.15

[PATCH 1/3] QReadWriteLock: fix data race in dtor

We need an acquire fence before we delete the d-pointer. Otherwise,
the reads that the dtor performs (QReadWriteLockPrivate contains many
non-trivial data types such as std::mutex and QVLA), race against
writes performed in other threads. The qWarning() indicates that
QReadWriteLock can not rely on external synchronization to ensure
a happens-before relationship between reads in the dtor and said writes.

While an explicit fence just before the delete would suffice, the guard
return is an extremely unlikely error case, and if we ignore it, then
loadAcquire() is correct, so use that.

Pick-to: 6.3 6.2 5.15
Change-Id: I29773b665a7f864cd6b07a294da326e8b10399b5
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 8af70190966e38dc3a697859f427276aecfe44d4)

[PATCH 2/3] QReadWriteLock: fix another data race in stateForWaitCondition()

The writerCount member variable is only ever accessed under
Private::mutex protection, so we need to lock the mutex here, too.

Pick-to: 6.3 6.2 5.15
Change-Id: I1717e5282eed2ecc14ccdc5090b9fc41174cccc8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 0ca2cf42e0de422634f13fb6a5e5a9d7560b323b)

[PATCH 3/3] QReadWriteLock: fix data race in stateForWaitCondition()

The function dereferences the load()ed pointer, so it needs an acquire fence.

Pick-to: 6.3 6.2 5.15
Change-Id: Ib951de3f00851d915fec3392cdaba64f4a994300
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 68f220c93b3e831a3f9b8cee0df6bd2ec69f7a11)

Merge request reports