MySQL Bugs: #28870: check that table locks are released/reset

Bug #28870	check that table locks are released/reset
Submitted:	4 Jun 2007 11:13	Modified:	6 Mar 2010 18:49
Reporter:	Sergey Vojtovich	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Locking	Severity:	S2 (Serious)
Version:	5.0, 5.1 and up	OS:	Any
Assigned to:	Davi Arnaut	CPU Architecture:	Any

Description:
This bug is reported by request from Ingo. We agreed that the problem described below is theoretically possible.

We need locking guru to assure that get_lock_data is followed by either unlock or reset_lock_data when it is needed. In other words we mustn't have released table object with lock type != TL_UNLOCK in a table cache, unless it is intentional.

For additional information see patch for BUG#28574.

Setting priority to P2 and severity to S2 because it may cause table corruptions or even server crash.

Also please check if it is worth to move several occurences of the sequence
reset_lock_data(sql_lock);my_free(sql_lock);sql_lock=0; to an error label.

How to repeat:
See lock.cc for get_lock_data().

Not quite get the problem from the description, but ready to help.

In a nutshell, this bug report is about the following:
 - mysql_lock_tables calls function get_lock_data
 - get_lock_data calls handler::store_lock, which updates lock_type of TABLE
 - in case when mysql_lock_tables fails later on, lock_type might be not reset back to TL_UNLOCK and the table might be returned to the table cache with wrong lock_type.
 - some branches of mysql_lock_tables are covered with reset_lock_data, which addresses specifically this problem, but not all branches. 
 - the fix for this bug is to ensure that reset_lock_data happens in all cases when get_lock_data failed and we back off, abort locks, or encounter an error in mysql_lock_tables.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/33500

ChangeSet@1.2510, 2007-08-30 23:00:33-03:00, davi@moksha.local +1 -0
  Bug#28870 check that table locks are released/reset
  
  The problem is that some mysql_lock_tables error paths are not resetting the
  tables lock type back to TL_UNLOCK. If the lock types are not reset properly,
  a table might be returned to the table cache with wrong lock_type.
  
  The proposed fix is to ensure that the tables lock type is always properly
  reset when mysql_lock_tables fails.

Sent a review by email.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/33992

ChangeSet@1.2510, 2007-09-10 10:28:32-03:00, davi@moksha.local +1 -0
  Bug#28870 check that table locks are released/reset
  
  The problem is that some mysql_lock_tables error paths are not resetting the
  tables lock type back to TL_UNLOCK. If the lock types are not reset properly,
  a table might be returned to the table cache with wrong lock_type.
  
  The proposed fix is to ensure that the tables lock type is always properly
  reset when mysql_lock_tables fails.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/34022

ChangeSet@1.2608, 2007-09-10 19:22:07-03:00, davi@moksha.local +11 -0
  Bug#28870 check that table locks are released/reset
  
  The problem is that some mysql_lock_tables error paths are not resetting the
  tables lock type back to TL_UNLOCK. If the lock types are not reset properly,
  a table might be returned to the table cache with wrong lock_type.
    
  The proposed fix is to ensure that the tables lock type is always properly
  reset when mysql_lock_tables fails. This is a incompatible change with respect
  to the process state information.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/34607

ChangeSet@1.2608, 2007-09-27 16:56:27-03:00, davi@moksha.local +4 -0
  Bug#28870 check that table locks are released/reset
    
  The problem is that some mysql_lock_tables error paths are not resetting the
  tables lock type back to TL_UNLOCK. If the lock types are not reset properly,
  a table might be returned to the table cache with wrong lock_type.
      
  The proposed fix is to ensure that the tables lock type is always properly
  reset when mysql_lock_tables fails. This is a incompatible change with respect
  to the process state information.

Pushed in 5.2.6

Pushed in 5.2.6

Internal change, no need for a changelog entry.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/91158

2925 Konstantin Osipov	2009-11-20
      Backport of:
      revno: 2476.784.2
      committer: davi@moksha.local
      timestamp: Thu 2007-09-27 16:56:27 -0300 
      message:
      Bug#28870 check that table locks are released/reset
          
      The problem is that some mysql_lock_tables error paths are not
      resetting the tables lock type back to TL_UNLOCK. If the lock
      types are not reset properly, a table might be returned to the
      table cache with wrong lock_type.
            
      The proposed fix is to ensure that the tables lock type is always
      properly reset when mysql_lock_tables fails. This is a
      incompatible change with respect to the process state information.
     @ sql/lock.cc
        Merge mysql_lock_tables cleanup sequence and the reset_lock_data
        function into a single function and take steps to ensure it is
        always called for each error exit path. Also remove references
        to the redundant THD::locked variable which was almost exclusively
        used by this function and the same information is already on proc_info.
     @ sql/sql_class.cc
        Remove references to the THD::locked variable.
     @ sql/sql_class.h
        Remove the THD::locked variable.
     @ sql/sql_show.cc
        Remove references to THD:locked, state_info will now default to proc_info.

Queued in next-mr-runtime (5.6)

Pushed into 6.0.14-alpha (revid:alik@sun.com-20091124194633-yc0achgq1ioyqzng) (version source revid:alik@sun.com-20091124194633-yc0achgq1ioyqzng) (merge vers: 6.0.14-alpha) (pib:13)

Pushed into 5.6.0-beta (revid:alik@sun.com-20091124193905-3iyzegd75k4givuz) (version source revid:kostja@sun.com-20091120191550-o212devfco01602d) (merge vers: 5.6.0-beta) (pib:13)

No changelog entry needed.

This needs to be documented as a incompatible change. It removed the "Locked" thread state.

Noted in 5.6.0, 6.0.14 changelogs.

The Locked thread state was equivalent to the Table lock state and
has been removed. It no longer appears in SHOW PROCESSLIST output.

Pushed into 5.5.3-m3 (revid:alik@sun.com-20100306103849-hha31z2enhh7jwt3) (version source revid:vvaintroub@mysql.com-20091125142014-7asc9sj33gzki0ym) (merge vers: 5.6.0-beta) (pib:16)

Moved 5.6.0 changelog entry to 5.5.3.