Page MenuHomeFreeBSD

thr_rtld: accept read lock requests while owning the lock for write
ClosedPublic

Authored by kib on May 2 2025, 3:38 PM.
Tags
None
Referenced Files
F149329627: D50117.diff
Mon, Mar 23, 7:16 PM
F149248724: D50117.id154711.diff
Mon, Mar 23, 7:00 AM
Unknown Object (File)
Fri, Mar 6, 6:32 PM
Unknown Object (File)
Feb 8 2026, 3:46 PM
Unknown Object (File)
Feb 8 2026, 1:06 AM
Unknown Object (File)
Jan 30 2026, 5:38 PM
Unknown Object (File)
Nov 13 2025, 2:46 PM
Unknown Object (File)
Nov 13 2025, 11:49 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib requested review of this revision.May 2 2025, 3:38 PM

The logic appears fine. Out of curiosity, could you describe or provide some links to the context of this change? I think I saw several changes passing in rtld recently, but haven't followed.

lib/libthr/thread/thr_rtld.c
175–182

That trick extends the write lock as seen by other threads until all the references from the locking thread have been released (write but also read). Could that be a problem?

This revision is now accepted and ready to land.May 2 2025, 4:15 PM

The logic appears fine. Out of curiosity, could you describe or provide some links to the context of this change? I think I saw several changes passing in rtld recently, but haven't followed.

See the referenced PR for the test case.

lib/libthr/thread/thr_rtld.c
175–182

This is the expected behavior, how could it be different? The last reference releases the exclusive/write lock.

Thanks, I hadn't seen it above.

lib/libthr/thread/thr_rtld.c
175–182

I was just wondering if that could be a problem in the context of the change. I do indeed see no other way without splitting _thr_rtld_lock_release() into 2 functions, one for the write lock and another one for read locks.