on Thu, 30 Apr 2026 16:41:27 -0700, Andrew Morton wrote: > So you're saying that this test is generally flakey and annoying?
Yes, this test item fails occasionally on the Android platform. The following are some responses to the code review of AI : > Does this leak the pthread_barrier_t resource? Since pthread_barrier_init() > is called to synchronize the newly created thread, should there be a matching > pthread_barrier_destroy() after the threads successfully rendezvous? Yes, the resource was not reclaimed by calling pthread_barrier_destroy here, and this issue has been resolved in the latest version. > If thread creation fails, EXPECT_EQ logs a failure but permits the test > execution to continue. This leaves the thread ID as 0, which would cause > subsequent functions to operate on uninitialized state. Could this lead to > cascading failures instead of safely halting the test, and should it remain > an ASSERT_EQ? Yes, this is a problem. It has also been resolved in the latest version. > Is it safe to ignore the return value of futex_wait_for_thread() here? > If the /proc filesystem is not mounted or accessible, opening > /proc/[tid]/wchan fails and returns -EIO instantly. Because the return > value is unhandled and the fallback sleep was removed, the parent thread > could immediately proceed to futex_cmp_requeue(). > This seems to reintroduce the race condition the commit sought to fix. Should > there be a check on the return value to ensure the test handles environments > without /proc properly, or perhaps a fallback delay? Yes, the situation when the /proc/[pid]/wchan file does not exist should be taken into consideration. yuwen
