Re: [RESEND PATCH v3] selftests/futex: fix the failed futex_requeue test issue

[Yuwen Chen <ywen.chen@foxmail.com>]

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