This is MySQL Bug#48883 (http://bugs.mysql.com/bug.php?id=48883).

The XtraDB INFORMATION_SCHEMA.INNODB_PLUGIN table is populated in a two-step
procedure. First, a table cache is filled with the real information, under the
kernel_mutex. This is only done if at least 100 milliseconds has passed since
last filling the cache. Second, the MySQL table data is populated from the
cache, which may thus be up to 100 milliseconds old.

There is a bug in the accounting for how often to do the first step. The
timestamp for last update is updated in step 2, not in step 1. This has two
consequences:

1. If the INNODB_PLUGIN table is queried very frequently repeatedly (with less
than 100 milliseconds interval in-between), stale data can be returned
indefinitely, as the "last updated" timestamp is reset even though step 1 is
not run. This is the problem seen in Bug#48883, and in MariaDB Buildbot.

2. If multiple queries against INNODB_PLUGIN start at around the same time,
they can all cause the cache to be updated, as the "last updated" timestamp
is not reset immediately after updating the cache. This can cause extra
unnecessary contention on kernel_mutex.

The failure is easy to repeat by changing the sleep in
mysql-test/include/wait_condition.inc from 0.1 to 0.01 seconds, and running
the innodb_information_schema.test.

I will attach a patch that fixes it.