Is buf_LRU_free_page() really supposed to make non-zip block sticky at the end?

Copy of http://bugs.mysql.com/bug.php?id=70228 for Percona Server.

[3 Sep 15:17] Laurynas Biveinis

Description:
buf_LRU_free_page() appears to either have redundant code to needlessly make the removed page sticky to the buffer pool, or at least a misleading comment.

How to repeat:
The relevant bits are:

bool
buf_LRU_free_page(...)
{
...
 ut_ad(buf_pool_mutex_own(buf_pool));
...
 if (!buf_LRU_block_remove_hashed(bpage, zip)) {
  return(true);
 }
...
 if (b) {
...
 } else {

  /* There can be multiple threads doing an LRU scan to
  free a block. The page_cleaner thread can be doing an
  LRU batch whereas user threads can potentially be doing
  multiple single page flushes. As we release
  buf_pool->mutex below we need to make sure that no one
  else considers this block as a victim for page
  replacement. This block is already out of page_hash
  and we are about to remove it from the LRU list and put
  it on the free list. */
  mutex_enter(block_mutex);
  buf_page_set_sticky(bpage);
  mutex_exit(block_mutex);
 }

 buf_pool_mutex_exit(buf_pool);
...
}

buf_LRU_block_remove_hashed will remove bpage from the LRU list. Thus it appears that
1) The comment "we need sure that no one else considers this block as a victim for page replacement" is false, as the block is not on the LRU list anymore where the victims are picked from;
2) There is no need to make the page sticky here and non-sticky below (not shown in the code snippet).

Suggested fix:
Remove else branch, make the final buf_page_unset_sticky() handle the b != NULL case only.