Fix bug #11934 Two sequential FLUSH TABLES WITH READ LOCK hangs client

Bug was introduced by cset 1.1659.14.1. Before it server was silently
ignoring that lock can't be acquired because it already acquired.

This patch makes make_global_read_lock_block_commit() return without error
if lock already acquired.

mysql-test/r/flush_table.result

@@ -101,3 +101,6 @@ table_id
 Record-02
 handler t1 close;
 drop table t1;
+FLUSH TABLES WITH READ LOCK ;
+FLUSH TABLES WITH READ LOCK ;
+UNLOCK TABLES;

mysql-test/t/flush_table.test

@@ -73,4 +73,11 @@ handler t1 read next limit 1;
 handler t1 close;
 drop table t1;
 
+#
+# Bug #11934 Two sequential FLUSH TABLES WITH READ LOCK hangs client
+#
+FLUSH TABLES WITH READ LOCK ;
+FLUSH TABLES WITH READ LOCK ;
+UNLOCK TABLES;
+
 # End of 4.1 tests

sql/lock.cc

@@ -990,7 +990,7 @@ bool make_global_read_lock_block_commit(THD *thd)
     make_global_read_lock_block_commit(), do nothing.
   */
   if (thd->global_read_lock != GOT_GLOBAL_READ_LOCK)
-    DBUG_RETURN(1);
+    DBUG_RETURN(0);
   pthread_mutex_lock(&LOCK_global_read_lock);
   /* increment this BEFORE waiting on cond (otherwise race cond) */
   global_read_lock_blocks_commit++;