From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 EB03A3A63F2 for ; Fri, 29 May 2026 21:27:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780090038; cv=none; b=fMI+OJa9/w/UsxjkQx9IcC0r1M4gBK3l0Yc154v1iiLsuE4d99DUZuBlbtE1YflmDjNaEW1AQHOnTRCf0Qsafo20wTA9b0GkaoaqXlCr0RLWstsEBoBjXIRpdU3UVeJijW17oXaEr1A7EOl4kG2ECXEzhO8IFNWvKh4OAB4mdaQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780090038; c=relaxed/simple; bh=H6fnExzMn7hfAy+AtOVpv9P5rqs9uhy755ui2NguaeE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Sw8QqLE3ue9QO9CG0dic0Akm7SMx9AniooSg030tiypPCcxf1OHdkrzSXmmDmRO9yD/to59VMLmapP7PqqKd9DaewBvitO7yDJWFz51TGnPk85RQQxBSu0dw0SBqnKmh+VkyGTq0sOZ86tqWSc6B0nbsfBJ2qrdYqjiwutPQr6Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MJ7DBWt6; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MJ7DBWt6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F06A41F00893; Fri, 29 May 2026 21:27:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780090037; bh=JcXTc/rPqe13DP03i28VNDHqxIb6HXwtn9GO9wSpIJc=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=MJ7DBWt6KsVuTpCnLLq2IqwApFaBxORZESddlbyxyTWCV/kz5F5dG68s0W9Ojgyo9 9GFKy8rPUgnzXgapE6+rZCF2odnRKHOhYZWvpdeXn1RxDiQaMjFBcOqXdAAiB0AUxx p4vWTahZp6OL7XBm9KMILwkir2t3nrqAVckr1R3D48yh9rLVCVS/B/Y5rtBd/24Wnn 13DUnuNgb5w+x0Du4tn6XUPrK5pmc74ZM4akjqo/eER7wbUWuZ9KWG2j/MMM+/U+Em 5xrrUzMndNGfy16fIFyZD16VebQwhq1JGCufzrpAxr10BNENLxueB5OEsLuZkCRLBC hTeZhXKbBF0uQ== From: Thomas Gleixner To: =?utf-8?Q?Andr=C3=A9?= Almeida , 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" , Uros Bizjak , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , kernel-dev@igalia.com Subject: Re: [PATCH 15/14] selftests: futex: Add tests for robust unlock within the critical section. In-Reply-To: References: <20260402151131.876492985@kernel.org> <20260404093939.7XgeW_54@linutronix.de> Date: Fri, 29 May 2026 23:27:14 +0200 Message-ID: <87cxyd9aa5.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, May 27 2026 at 23:55, Andr=C3=A9 Almeida wrote: > Em 04/04/2026 06:39, Sebastian Andrzej Siewior escreveu: >> + >> + } else if (state =3D=3D 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 &=3D 0xffffffff; >> + >> + ASSERT_EQ(rhead_val, 0); >> + ASSERT_EQ(lock_val, 0); >> + } > > It turns out that the test success I saw with my aarch64 implementation=20 > was a false positive :/ There's no logic to verify if the code really=20 > enters the critical section. If the code just jump over it, the test=20 > 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=20 > should add max steps?). The single steps doesn't work for LL/SC locks,=20 > 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=20 > exclusive monitor[1], so store fails and the code branches to retry. We=20 > need to jump straight to `cbnz %w[result], retry`. I tested to single=20 > step with GDB, and it turns outs that it is smart enough to run the code= =20 > from ldxr to stlxr "atomically", to avoid messing with the exclusive=20 > monitor and then it worked as expected. That's why I put the labels into the ASM so that the test can set breakpoints at the proper points and check whether the kernel/vdso did the right thing. Single stepping is not really a good idea because you can't test the interruption points, which matter correctly. Thanks, tglx