--Thread 139558755972864 has waited at btr0sea.c line 1197 for 930.00 seconds the semaphore:
X-lock (wait_ex) on RW-latch at 0x9390f558 'btr_search_latch_part[i]'
a writer (thread id 139558755972864) has reserved it in mode wait exclusive
number of readers 1, waiters flag 1, lock_word: ffffffffffffffff
Last time read locked in file btr0sea.c line 1099
Last time write locked in file /home/jenkins/workspace/percona-server-5.5-rpms/label_exp/centos6-64/target/BUILD/Percona-Server-5.5.27-rel28.1/Percona-Server-5.5.27-rel28.1/storage/innobase/btr/btr0sea.c line 669
InnoDB: Warning: a long semaphore wait:

While checking an AHI-related issue, I noticed that
mem_heap_create_block uses buf_block_alloc which round robins
through available buffer pools. So, in the presence of multiple
partitions and multiple buffer pools, can it be possible that
the locking meant for one pool is used for another, resulting in
deadlock?

----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 4641988, signal count 327450531
--Thread 1219737920 has waited at row0sel.c line 3698 for 0.0000 seconds the semaphore:
S-lock on RW-latch at 0x29ea4b18 'btr_search_latch_part[i]'
number of readers 0, waiters flag 0, lock_word: 100000
Last time read locked in file btr0sea.c line 918
Last time write locked in file /home/jenkins/workspace/percona-server-5.5-rpms/label_exp/centos5-64/target/BUILD/Percona-Server-5.5.22-rel25.2/Percona-Server-5.5.22-rel25.2/storage/innobase/btr/btr0sea.c line 669
--Thread 1218406720 has waited at btr0sea.c line 1508 for 0.0000 seconds the semaphore:
S-lock on RW-latch at 0x29ea4b18 'btr_search_latch_part[i]'
number of readers 0, waiters flag 0, lock_word: 100000
Last time read locked in file btr0sea.c line 918
Last time write locked in file /home/jenkins/workspace/percona-server-5.5-rpms/label_exp/centos5-64/target/BUILD/Percona-Server-5.5.22-rel25.2/Percona-Server-5.5.22-rel25.2/storage/innobase/btr/btr0sea.c line 669
--Thread 1219205440 has waited at btr0sea.c line 1508 for 0.0000 seconds the semaphore:
S-lock on RW-latch at 0x29ea4b18 'btr_search_latch_part[i]'
number of readers 0, waiters flag 0, lock_word: 100000
Last time read locked in file btr0sea.c line 918

Thus, it checks all the latches for the X waiters and collects a bitmask of them. That bitmask is only used if any bit is set, and if yes, the S latches are released for which the current transaction thinks it has the latch for. The individual bit info in the should_release is not used at all. The should_release and trx->has_search_latch bitmasks are not identical.

And even that is suboptimal. The proposed code just interrupts the loop early as soon as we found a latch with X waiters. 2 problems:

1. the current thread will release all latches, even if there are only X waiters on latches it doesn't own.
2. the current thread will release all latches, though it may be sufficient to release only some.