lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <tencent_38F3843C852F8CAECF22386E81F151D7A207@qq.com>
Date: Mon, 15 Dec 2025 15:50:33 +0800
From: Yuwen Chen <ywen.chen@...mail.com>
To: licayy@...mail.com
Cc: akpm@...ux-foundation.org,
	andrealmeid@...lia.com,
	dave@...olabs.net,
	dbueso@...e.de,
	dvhart@...radead.org,
	edliaw@...gle.com,
	hpa@...ux.intel.com,
	justinstitt@...gle.com,
	kernel-team@...roid.com,
	licayy@...look.com,
	linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	llvm@...ts.linux.dev,
	luto@....edu,
	mingo@...hat.com,
	morbo@...gle.com,
	nathan@...nel.org,
	ndesaulniers@...gle.com,
	peterz@...radead.org,
	shuah@...nel.org,
	tglx@...utronix.de,
	usama.anjum@...labora.com,
	ywen.chen@...mail.com
Subject: Re: [PATCH 3/3] selftests/futex: fix the issue of abnormal test results caused by thread timing

on Fri, 12 Dec 2025 12:30:20 +0800, Licay wrote:
> 1. Avoid Parsing /proc
>    The current approach uses get_thread_state() to read /proc/$pid/status, which isn't very reliable.
>    A better way would be to have waiterfn directly signal when it's ready using atomic operations.

I haven't found a better way to check whether a process has entered the
sleep state without using the proc interface for the time being. The kernel
probably doesn't provide a system call to obtain whether a process has
entered the sleep state.

> 2. Use Atomic Counting Instead of Polling Thread State
>    Before entering futex_wait, waiterfn can atomically increment a counter. The parent thread then just waits for this counter to reach the expected value.
>    This is much simpler and avoids the overhead of checking /proc repeatedly.

Using atomic instructions does not guarantee that the process is waiting in futex_wait.

> 3. Use Standard Atomic Types
>    Replace the custom READ_ONCE/WRITE_ONCE macros with standard <stdatomic.h> types like atomic_int.
>    It's cleaner and more portable across different platforms.

Only two operations, atomic_set and atomic_read, are used here. Using
WRITE_ONCE and READ_ONCE can avoid introducing too many dependencies.

> Here's the basic idea:
> - Add a global atomic_int ready_count variable
> - In waiterfn: atomic_fetch_add(&ready_count, 1) right before futex_wait()
> - Parent thread: spin-wait until atomic_load(&ready_count) reaches the expected value

Similarly, using atomic_inc before futex_wait does not guarantee that
the thread has reached the futex_wait execution point.

Thank you very much for your reply.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ