Bug#13537504 VALGRIND: COND. JUMP/MOVE DEPENDS ON UNINITIALISED VALUES

IN OS_THREAD_EQ

rb://977
approved by: Marko Makela

rw_lock::writer_thread field contains the thread id of current x-holder
or wait-x thread. This field is un-initialized at lock creation and is
written to for the first time when an attempt is made to x-lock.

Current code considers ::writer_thread as valid memory region only when
the lock is held in x-mode (or there is an x-waiter). This is an
overkill and it generates valgrind warnings.

The fix is to consider ::writer_thread as valid memory region once it
has been written to.

Reasoning:
==========
The ::writer_thread can be safely considered valid because:

* We only ever do comparison with current calling threads id.
* We only ever do comparison when ::recursive flag is set
* We always unset ::recursive flag in x-unlock
* Same thread cannot be unlocking and attempting to lock at the same
time
* thread_id recycling is not an issue because before an id is recycled
the thread must leave innodb meaning it must release all locks meaning
it must unset ::recursive flag.

storage/innodb_plugin/ChangeLog

+2012-03-15	The InnoDB Team
+
+	* include/sync0rw.ic:
+	Fix Bug#13537504 VALGRIND: COND. JUMP/MOVE DEPENDS ON
+	UNINITIALISED VALUES IN OS_THREAD_EQ
+
 2012-03-08	The InnoDB Team
 
 	* btr/btr0pcur.c:

storage/innodb_plugin/include/sync0rw.ic

@@ -564,8 +564,6 @@ rw_lock_x_unlock_func(
 	if (lock->lock_word == 0) {
 		/* Last caller in a possible recursive chain. */
 		lock->recursive = FALSE;
-		UNIV_MEM_INVALID(&lock->writer_thread,
-				 sizeof lock->writer_thread);
 	}
 
 #ifdef UNIV_SYNC_DEBUG
@@ -606,8 +604,6 @@ rw_lock_x_unlock_direct(
 
 	if (lock->lock_word == 0) {
 		lock->recursive = FALSE;
-		UNIV_MEM_INVALID(&lock->writer_thread,
-				 sizeof lock->writer_thread);
 	}
 
 #ifdef UNIV_SYNC_DEBUG