Deadlock in RELEASE_LOCK()

Bug #1405076 reported by Alexey Kopytov
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to
Fix Released
Alexey Kopytov
Fix Released
Alexey Kopytov

Bug Description

The RELEASE_LOCK() implementation introduced by the multiple user level locks patch can result in a deadlock under the following conditions:

- connection #1 calls RELEASE_LOCK() for a previously acquired lock. In which case MDL_lock::remove_ticket() is called, which write-locks MDL_lock::m_rwlock corresponding to the user-level MDL object. With that lock held, MDL_map_partition::remove() is called which locks MDL_map_partition::m_mutex protecting the hash of MDL locks belonging to an MDL partition.

- connection #2 calls RELEASE_LOCK() simultaneously for the same lock being released by connection #1. Since connection #2 did not own the lock, it calls MDL_map_partition::get_lock_owner() to check if 0 or NULL should be returned (i.e. if the lock exists). That function also locks both MDL_map_partition::m_mutex and MDL_lock::m_rwlock(), but in the reverse order as compared to connection #1.

With the right timing for the above events we get each thread waiting for a lock acquired by the other thread, i.e. a deadlock.

Tags: i48942

Related branches

tags: added: i48942
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to:

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.