[Bug 269277] On 12.3, process-shared mutex may fail locking operations after usage of ANOTHER process-shared mutex.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269277 Xin LI changed: What|Removed |Added CC||delp...@freebsd.org Assignee|b...@freebsd.org|k...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269277] On 12.3, process-shared mutex may fail locking operations after usage of ANOTHER process-shared mutex.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269277 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c8452bdeed4fc1f1feadf36c6008367263292254 commit c8452bdeed4fc1f1feadf36c6008367263292254 Author: Konstantin Belousov AuthorDate: 2023-02-01 20:12:45 + Commit: Konstantin Belousov CommitDate: 2023-02-08 00:26:59 + libthr pshared: correct a bug in allocation PR: 269277 (cherry picked from commit 25c862ae503a1c99458f4e055fd50c878fadbea3) lib/libthr/thread/thr_pshared.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269277] On 12.3, process-shared mutex may fail locking operations after usage of ANOTHER process-shared mutex.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269277 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=25c862ae503a1c99458f4e055fd50c878fadbea3 commit 25c862ae503a1c99458f4e055fd50c878fadbea3 Author: Konstantin Belousov AuthorDate: 2023-02-01 20:12:45 + Commit: Konstantin Belousov CommitDate: 2023-02-01 22:59:27 + libthr pshared: correct a bug in allocation When __thr_pshared_offpage() is called for allocation, it must not use the cached offpage for the key. Instead, the cached offpage must be unmapped and removed from the cache, if any. It is legitimate for the user code to unmap the shared lock object without destroying it, and then mapping something over the freed VA to carry another shared lock. In this case the cached offpage must be un-cached. PR: 269277 Reported by:rau8...@gmail.com Reviewed by:markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D38345 lib/libthr/thread/thr_pshared.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269277] On 12.3, process-shared mutex may fail locking operations after usage of ANOTHER process-shared mutex.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269277 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #1 from Konstantin Belousov --- https://reviews.freebsd.org/D38345 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269277] On 12.3, process-shared mutex may fail locking operations after usage of ANOTHER process-shared mutex.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269277 Bug ID: 269277 Summary: On 12.3, process-shared mutex may fail locking operations after usage of ANOTHER process-shared mutex. Product: Base System Version: 12.3-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rau8...@gmail.com Created attachment 239841 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239841=edit Minimal code to recreate issue On FreeBSD 12.3 amd64, a process-shared mutex may fail locking operations after usage of ANOTHER process-shared mutex. Original issue was seen running a particular sequence of unit tests against a complex codebase; sometimes saw two threads lock the same mutex at the same time, or fail on lock with EINVAL. Issue recreated Recreated the EINVAL issue with a minimal example on a single thread (see attached), both with gtest and without. Tested on two physical quad-core machines (a Beckhoff 2040 and a Beckhoff 2042). -- You are receiving this mail because: You are the assignee for the bug.
