When mleich tested a port of MDEV-27812 to MariaDB Enterprise Server 10.6, he noticed that an attempt to execute multiple concurrent SET GLOBAL innodb_log_file_size=...; would result in long waits. The culprit turned out to be an incorrect choice of a condition variable in a timed wait:

diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc

index 407834f2008..06af558a2e7 100644

--- a/storage/innobase/handler/ha_innodb.cc

+++ b/storage/innobase/handler/ha_innodb.cc

@@ -18452,7 +18452,7 @@ static void innodb_log_file_size_update(THD *thd, st_mysql_sys_var*,

         const bool in_progress(buf_pool.get_oldest_modification(LSN_MAX) <

                                log_sys.resize_in_progress());

         if (in_progress)

-          my_cond_timedwait(&buf_pool.do_flush_list,

+          my_cond_timedwait(&buf_pool.done_flush_list,

                             &buf_pool.flush_list_mutex.m_mutex, &abstime);

         mysql_mutex_unlock(&buf_pool.flush_list_mutex);

         if (!log_sys.resize_in_progress())

The condition variable buf_pool.done_flush_list is broadcast by the buf_flush_page_cleaner() after the end of each batch, which is when the log checkpoint can advance and where any log resizing may be completed. The purpose of the condition variable buf_pool.do_flush_list is to wake up the buf_flush_page_cleaner() thread because there is work to do. If no thread is signaling that condition variable, this loop could unnecessarily wait for up to 5 seconds too long for the log resizing to be completed. By consuming signals it could also prevent the buf_flush_page_cleaner() thread from waking up.