From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6969D255F28 for ; Thu, 28 May 2026 02:55:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.97.179.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779936926; cv=none; b=tycmqQcdu4W2rjwXWKJ/2tNTMRcd2tQsXUkI0ywnxT3/t5X45J+KW/By3m34DE9eF3jsmPFngE8vRaFphoJ4RSfKIhAVMkBRIi/AhV7D2eNac3Wtgi2hlR23QfEmLm0kRm0cHmqZcOBxjLlMjKV/dk/Z7+N+de8x09on3chUJUY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779936926; c=relaxed/simple; bh=v/YX2r+FOxCiDUFLAMscue5ICEl4YwllnIkaJA8E21g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UPCuhzr0/41hsXCNj4wz3VgvYrhijMrq7QVmUb30APE+k7UKsFmNkJK0CrCSkMeVKF6ETFZhAgPTmbRISbHKXgAG8zon4YcU/OfPVhO3zte3WntxR/rbji8XcAoqAe2jvgYam6KE42tjzX1VKhTRz+mynsJbp78c0a6lygxefts= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com; spf=pass smtp.mailfrom=igalia.com; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b=nWH38r4A; arc=none smtp.client-ip=213.97.179.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=igalia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b="nWH38r4A" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=XpQ8YjX2hX9vh0PjeM75oSK3kvofLDTOyIKwKArENR0=; b=nWH38r4AzcjcL0CEeJtAuk/s+e 1+F6dbeNa776O/rE2+P950o9drYxZL/saQH4b/CeNnIzrEbW6H0Xl5TJ0ulcyIoLj2bhf4fpgMeRS savaFGFG7Uod9yLLlcDW05Jka3bfqT8MTLtukGemdQ6lh3+xmeRumIw0HtfkIQkbYu8jnan9FEXvY 5s7C6CtF9nqR2apWZiYSlgl1NT2x92kIw99eKzy8n+/iDA6DKYjpKYVOOnnIUZlGb237pFHi2z0xZ nKenSD0Q/I3n/pjageCUAS959FangdsXxzQG2+1d+sozUfDoMqVYPUvDZtYYR4v9HWsKcjfg5rYBP mEBvcraw==; Received: from [179.118.191.12] (helo=[192.168.15.100]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1wSQtx-009Azv-8x; Thu, 28 May 2026 04:55:17 +0200 Message-ID: Date: Wed, 27 May 2026 23:55:10 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 15/14] selftests: futex: Add tests for robust unlock within the critical section. To: Sebastian Andrzej Siewior Cc: LKML , Mathieu Desnoyers , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" , Thomas Gleixner , Uros Bizjak , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , kernel-dev@igalia.com References: <20260402151131.876492985@kernel.org> <20260404093939.7XgeW_54@linutronix.de> Content-Language: en-US From: =?UTF-8?Q?Andr=C3=A9_Almeida?= In-Reply-To: <20260404093939.7XgeW_54@linutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Em 04/04/2026 06:39, Sebastian Andrzej Siewior escreveu: > From: Sebastian Andrzej Siewior > > I took Thomas’ initial test case from the cover letter and reworked it > so that it uses ptrace() to single‑step through the VDSO unlock > operation. The test expects the lock to remain locked, with > `list_op_pending' pointing somewhere, when entering the VDSO unlock > path. Once execution steps into the critical section, it expects the > kernel to perform the fixup that is, to unlock the lock and clear > `list_op_pending'. > > The test requires VDSO debug symbols, typically provided by > vdso64.so.dbg or vdso32.so.dbg. It attempts to locate the appropriate > file automatically, but the user may override this by setting the > VDSO_DBG environment variable. If neither method succeeds, libelf falls > back to its usual lookup mechanism under /usr/lib/debug/.build-id/ > > Signed-off-by: Sebastian Andrzej Siewior [...] > + > + } else if (state == STATE_IN_CS) { > + /* > + * If the critical section has been entered then > + * the kernel has to unlock and clean list_op_pending. > + * On 32bit the pointer is just 32bit wide, the > + * upper 32bit are cleaned on 64bit. > + */ > + if (is_32bit) > + rhead_val &= 0xffffffff; > + > + ASSERT_EQ(rhead_val, 0); > + ASSERT_EQ(lock_val, 0); > + } It turns out that the test success I saw with my aarch64 implementation was a false positive :/ There's no logic to verify if the code really enters the critical section. If the code just jump over it, the test never checks if lock_val and rhead_val are actually zeroed. > + > + if (ptrace(PTRACE_SINGLESTEP, child, 0, 0)) > + err(1, "PTRACE_SINGLESTEP"); After I fixed my code, the selftest got to an infinity loop (maybe we should add max steps?). The single steps doesn't work for LL/SC locks, like this one: retry: ldxr %w[val], %[lock] cmp %w[tid], %w[val] bne end stlxr %w[result], wzr, %[lock] cbnz %w[result], retry end: The single step with ptrace() causes a context switch that clear the exclusive monitor[1], so store fails and the code branches to retry. We need to jump straight to `cbnz %w[result], retry`. I tested to single step with GDB, and it turns outs that it is smart enough to run the code from ldxr to stlxr "atomically", to avoid messing with the exclusive monitor and then it worked as expected. [1] https://developer.arm.com/documentation/dht0008/a/arm-synchronization-primitives/exclusive-accesses/exclusive-monitors [2] https://github.com/gnutools/binutils-gdb/blob/aa5685c0fa9f299ae0f94e537a1f55991c972e9c/gdb/aarch64-tdep.c#L3514