Percona Server moved to https://jira.percona.com/projects/PS

lp:~laurynas-biveinis/percona-server/bug1407941-5.6

Created by Laurynas Biveinis on 2015-01-07 and last modified on 2015-01-07

Get this branch:: bzr branch lp:~laurynas-biveinis/percona-server/bug1407941-5.6

Only Laurynas Biveinis can upload to this branch. If you are Laurynas Biveinis please log in for upload directions.

Branch merges

Merged into lp:percona-server/5.6 at revision 724

Laurynas Biveinis (community): Approve on 2015-01-07

Low

Fix Released

Link a bug report

Related blueprints

Branch information

Owner:: Laurynas Biveinis

Project:: Percona Server moved to https://jira.percona.com/projects/PS

Status:: Merged

Recent revisions

724. By Laurynas Biveinis on 2015-01-07

Merge bug 1407941 fix from 5.5. The 5.6 version of the fix is to shift
the purge worker thread ids towards the threads_id array end. Bump
srv_max_n_threads for the log tracker thread.

723. By Laurynas Biveinis on 2015-01-06

Automerge lp:~laurynas-biveinis/percona-server/bug1337251

722. By Laurynas Biveinis on 2015-01-06

Automerge lp:~laurynas-biveinis/percona-server/bug1404565

721. By Laurynas Biveinis on 2015-01-06

Automerge lp:~sergei.glushchenko/percona-server/5.6-ST47191-ps-bug1294190

720. By Tomislav Plavcic on 2015-01-05

Merged lp:~tplavcic/percona-server/bug1405667-5.6

719. By Laurynas Biveinis on 2014-12-31

Automerge lp:~laurynas-biveinis/percona-server/bug1268656

718. By Alexey Kopytov on 2014-12-23

Bug #1405076: Deadlock in RELEASE_LOCK()

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.

Fixed by avoiding to lock MDL_lock::m_rwlock with
MDL_map_partition::m_mutex locked. There is already infrastructure to
release the latter and acquire the former and guarantee that a reference
to an MDL_lock object is valid at the same time. It is implemented in
MDL_map_partition::move_from_hash_to_lock_mutex(), so the fix utilizes
it to remove the deadlock condition.