1
2
Fork
You've already forked spin
0

Panic from debug assertion when calling RwLockWriteGuard::downgrade_to_upgradeable #169

Open
opened 2024年11月21日 00:46:22 +01:00 by an-owl · 1 comment
an-owl commented 2024年11月21日 00:46:22 +01:00 (Migrated from github.com)
Copy link

RwLock::try_upgradeable_read() is

 pub fn try_upgradeable_read(&self) -> Option<RwLockUpgradableGuard<T, R>> {
 if self.lock.fetch_or(UPGRADED, Ordering::Acquire) & (WRITER | UPGRADED) == 0 {
 Some(RwLockUpgradableGuard {
 phantom: PhantomData,
 inner: self,
 data: unsafe { &*self.data.get() },
 })
 } else {
 // We can't unflip the UPGRADED bit back just yet as there is another upgradeable or write lock.
 // When they unlock, they will clear the bit.
 None
 }
 }

RwLockUpgradableGuard::try_upgrade_internal() contains compare_exchange( &inner.lock, UPGRADED, WRITER, Ordering::Acquire, Ordering::Relaxed,strong ) which clears UPGRADED and sets WRITER.

If try_upgrade_internal() is called then UPGRADED is cleared and WRITER is set. If try_upgradeable_read() is called on another thread this will set UPGRADED and return None, as it mentions in the fail branch it cant clear UPGRADED and the owner of the lock must clear it. However a number of debug assertions particularly in RwLockWriteGuard::downgrade_to_upgradeable and RwLockUpgradableGuard::drop() will panic in this event, even though RwLockWriteGuard::downgrade_to_upgradeable clears both UPGRADED and WRITER

`RwLock::try_upgradeable_read()` is ``` pub fn try_upgradeable_read(&self) -> Option<RwLockUpgradableGuard<T, R>> { if self.lock.fetch_or(UPGRADED, Ordering::Acquire) & (WRITER | UPGRADED) == 0 { Some(RwLockUpgradableGuard { phantom: PhantomData, inner: self, data: unsafe { &*self.data.get() }, }) } else { // We can't unflip the UPGRADED bit back just yet as there is another upgradeable or write lock. // When they unlock, they will clear the bit. None } } ``` `RwLockUpgradableGuard::try_upgrade_internal()` contains `compare_exchange( &inner.lock, UPGRADED, WRITER, Ordering::Acquire, Ordering::Relaxed,strong )` which clears `UPGRADED` and sets `WRITER`. If `try_upgrade_internal()` is called then `UPGRADED` is cleared and `WRITER` is set. If `try_upgradeable_read()` is called on another thread this will set `UPGRADED` and return `None`, as it mentions in the fail branch it cant clear `UPGRADED` and the owner of the lock must clear it. However a number of debug assertions particularly in `RwLockWriteGuard::downgrade_to_upgradeable` and `RwLockUpgradableGuard::drop()` will panic in this event, even though `RwLockWriteGuard::downgrade_to_upgradeable` clears both `UPGRADED` and `WRITER`
zesterer commented 2024年11月26日 21:17:51 +01:00 (Migrated from github.com)
Copy link

Thanks for the report, I'll try to look over this in more detail soon.

Thanks for the report, I'll try to look over this in more detail soon.
Sign in to join this conversation.
No Branch/Tag specified
master
fixes
fix-ub
revert-127-ci
spinlock
No results found.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
zesterer/spin#169
Reference in a new issue
zesterer/spin
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?