From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D49423B9DB8 for ; Thu, 12 Mar 2026 09:29:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773307794; cv=none; b=jf8kzc6QoAclcVwXiDzY/ay8oadm9GB/DNiY+bkpwhkAK+jzVLxp2H/ZSQH/yKt/BfWAnerjCQS8NlhvqoRTZ0Y+7Wdhx7y8Wj14q+algYR5Kt1dBLH94QRGmAxlHqFy/2ZFZr4zTlfJd2w8j5v85MukaFBtoVWg6F9XOyupCwI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773307794; c=relaxed/simple; bh=q6MJzu5+YHTxdljkNnf4jYTKza5wayB6oEnOn3+6DDQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IZ40tkVep1BYwB2o5zip6tDI2TkZhSS4bMWRJZdezwQ6TKQx9hG9o5cWSSJNrCuHFl6v+VGuxxVOQ0zSG0ujPxCjeL+QQw/AHC/Sg1KPcKMTAx9sriPjPtoYCdf4MB9Zs1EAS5TP7bsvzkJe+yG8mRusQ8D6uBWpmvz37PyDdvQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=C1sqqjZ8; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="C1sqqjZ8" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-48534b59cf3so7085535e9.2 for ; Thu, 12 Mar 2026 02:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773307791; x=1773912591; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=48ePxsccF8Uxw25h+Bp/9IWess/Z+mmqJesR4Y9xVUk=; b=C1sqqjZ8I76GesOi6bSahMnXcuAUhRFgEFKzx1VkmyNoqXzE/KH+JPefNJsqUO/xyn dvcUgdbxxsw2SzfTz84M+5OW7pSS7dqhkz6FF/S6/NMAbkWT7TMNRLHhnxEQ4A7YmMMW NDZFOo2eFNK8YXisbY2zeGvvTAVr5yDB+vm3BZf+8Y+LZkrf3Qo4wovAdy2c/HjD7MLh cMPVWTocIPJ4ETCxoXWpP2mNtH1+pkGI5YPsgVSk8l780NW928gXaUyExR27a9x/Sk8r mYXudArbtw2vjTESMa6boVd1IsOe/L6QNdv5hxXWDZD6ohmfT/zxiIfA46ekejMTVbZI NDwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773307791; x=1773912591; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=48ePxsccF8Uxw25h+Bp/9IWess/Z+mmqJesR4Y9xVUk=; b=qDl/H5bHVjhDfZ4FEyckoT8Go9YG4MzVcaY2QB7X9hYWlC1jg9sNwXNXm1v3crnZ+8 MSGu2PO6yywjAylgNZDX8EtTyRepwuH1shCQeYIb/tBKUMeTjZHb4lqgqY3A8ZRKd5sc O0VNKZeAQnPDFsfhpOdlwOOnO47qJL5CZwL2pP+6BHz0TRElOausjbWe65IH0DxDKUbb FViKd7QEME9POdWYtfkyCMf81JStEEp3XCV1fPo5AWvObHXMPIYPHitDQsjxMmRaCAEm 3EJ+nqurT4xbH/lFEC8fWKxhxMCy9VmyY42oYUVvMrVk4s4/o8fMnIo99sulMb1dsmj+ DkbA== X-Forwarded-Encrypted: i=1; AJvYcCU8Yotm09Fq/ydK9sfjngFfVHCcQvJZ0vASmiLsz6SzvgBaaVj2mzWo08M5zZp6A+pC/DcxxNeLBZ5cuTM=@vger.kernel.org X-Gm-Message-State: AOJu0YywxUrIkeIbexPOiKbzksv8oggF2J7uyYS3dOtwFF/taGHdiew+ E1wFkm97S+j4UTs4f6jCR/cYqe/PidV4o8aW+qy5JAdtBiDllXCHhIye X-Gm-Gg: ATEYQzzDsVANlPwTFoQ8iKbF3BHX9yvQnVIJ/2uxgGx5pgQco4/D2b6PClSFONqIDlD 2qwusM6E0Z5cvH0WtOQ6QKkiNot+BNRZUO4HkukqUin0oDbR9f4WF2iRVovV+W2dPq6P8X2a0DZ F6R5JdTJvrXHlrvvjBKujOOkbHDZflXxAi8FyAMejlhhORvgfYFTOYGft6CfbMF5Kq5WRx2zggQ EYagA5nswj7I0Z4uBTpF+jEfl4q8Fg+uZi3OyQXNAR12L9m87iQTFqBitLmuZnxxpmZhUMOmTaR LRSoNkU82SecGagcHe3j95B2chO3skKbbHPExuk/cwcDIsZPTHzTxrEUF2W+R267R3BDHwcYC2I ZZvPYq97YQhtoqv1OQP8IgKEblbDGpfF3sYfvOraWiSZWA38ic8QVaujTt7cXaf/tPop18Tlp4z MqNI2Q+AIf9inaM+iIyHLgFToAAMAncIKH4DUDnDU0P+zs7+++pyxaZBvrclB4WIaoVM6sHmJL8 nd9k8njNRKoZQ3YOO2SKjDIZ/Moon3c8fVrIJscf0PsHDpqGAp1CcVjx8mOe7tG9Mr8miaBVkn6 GSUYOveyEca2JojngemlIg== X-Received: by 2002:a05:600c:6090:b0:485:4278:24fb with SMTP id 5b1f17b1804b1-4854b13c02emr94171935e9.32.1773307790948; Thu, 12 Mar 2026 02:29:50 -0700 (PDT) Received: from mail.gmail.com (2a01cb0889497e00e621310b96d0fd4d.ipv6.abo.wanadoo.fr. [2a01:cb08:8949:7e00:e621:310b:96d0:fd4d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4854a2fd030sm70819185e9.2.2026.03.12.02.29.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 02:29:50 -0700 (PDT) Date: Thu, 12 Mar 2026 10:29:47 +0100 From: Paul Chaignon To: Tiezhu Yang Cc: Emil Tsalapatis , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Hengqi Chen , loongarch@lists.linux.dev, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH bpf-next v1 1/2] selftests/bpf: Check alignment flag if expected result is REJECT Message-ID: References: <20260310064507.4228-1-yangtiezhu@loongson.cn> <20260310064507.4228-2-yangtiezhu@loongson.cn> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Mar 12, 2026 at 02:59:57PM +0800, Tiezhu Yang wrote: > Hi Emil and Paul, Hi Tiezhu, > > On 2026/3/11 下午11:56, Emil Tsalapatis wrote: > > On Tue Mar 10, 2026 at 2:45 AM EDT, Tiezhu Yang wrote: > > > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set unconditionally for the > > > most archs such as x86_64, aarch64, ppc64el and s390x, but this config > > > may be not set by users for riscv64 and loongarch64. > > > > > > If CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is not set, the BPF verifier > > > detects if a program has unaligned access and then rejects them. So it > > > should also check the flag F_NEEDS_EFFICIENT_UNALIGNED_ACCESS if the > > > expected result is REJECT and set alignment_prevented_execution as 1, > > > then the message "(NOTE: not executed due to unknown alignment)" can > > > be printed for some testcases of test_verifier to reflect the reality. > > > > > > Signed-off-by: Tiezhu Yang > > > --- > > > tools/testing/selftests/bpf/test_verifier.c | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c > > > index a8ae03c57bba..a1ae2f044e96 100644 > > > --- a/tools/testing/selftests/bpf/test_verifier.c > > > +++ b/tools/testing/selftests/bpf/test_verifier.c > > > @@ -1640,6 +1640,11 @@ static void do_test_single(struct bpf_test *test, bool unpriv, > > > printf("FAIL\nUnexpected success to load!\n"); > > > goto fail_log; > > > } > > > +#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > > > + if (fd_prog < 0 && > > > + (test->flags & F_NEEDS_EFFICIENT_UNALIGNED_ACCESS)) > > > + alignment_prevented_execution = 1; > > > +#endif > > > > This doesn't look like it's breaking anything, but it will cause all > > tests with F_NEEDS_EFFICIENT_UNALIGNED ACCESS to be reported as failing > > due to unaligned accesses even if they actually failed due to expected > > errors at load time. > > > > Which test programs is this fix targeted towards? Can't we just skip > > those tests for riscv/loongarch instead of adding this workaround? > > Thanks for your reviews. > > It does not fix any failed testcases, the testcases passed without > and with this patch. It only affects the output for some testcases > such as test_verifier 14, 153, 190, 191, 193, 197, 200, 201, 202, > 204, 255, 256, 295, 297, 298, 300, 301, 302, 307, 308, 331, 341, > 342, 475, 477, 500, 512, 514, 515, 517, 520, 522, 523, 525. > > For example, for the test_verifier 14, > verifier/atomic_cmpxchg.c:215 > "Dest pointer in r0 - succeed, check 5", > if remove ".flags = F_NEEDS_EFFICIENT_UNALIGNED_ACCESS,", I think I'm missing something. Why would you remove this flag? Are you trying to illustrate that this is a program that could be rejected because of misaligned accesses? I agree, but here the flag is set and this program is therefore rejected because of an invalid memory access; the misalgined access check is skipped in the verifier. > here is the test result if HAVE_EFFICIENT_UNALIGNED_ACCESS is not set: > > $ sudo ./test_verifier 14 > #14/u Dest pointer in r0 - succeed, check 5 OK > #14/p Dest pointer in r0 - succeed, check 5 FAIL > Unexpected verifier log! > EXP: R0 invalid mem access > RES: > FAIL > Unexpected error message! > EXP: R0 invalid mem access > RES: misaligned access off (0x0; 0xffffffff)+-8 size 4 > verification time 27 usec > stack depth 8 > processed 5 insns (limit 1000000) max_states_per_insn 0 total_states 0 > peak_states 0 mark_read 0 > > misaligned access off (0x0; 0xffffffff)+-8 size 4 > verification time 27 usec > stack depth 8 > processed 5 insns (limit 1000000) max_states_per_insn 0 total_states 0 > peak_states 0 mark_read 0 > Summary: 1 PASSED, 0 SKIPPED, 1 FAILED > > It seems that this is because the program has unaligned accesses, > but the kernel sets CONFIG_ARCH_STRICT_ALIGN by default to enable > -mstrict-align to prevent unaligned accesses. > > So I think add "(NOTE: not executed due to unknown alignment)" to the > output is reasonable. Something I missed? > > Without this patch: > > sudo ./test_verifier > log.before > > With this patch: > > sudo ./test_verifier > log.after > > Here is the diff: > > $ diff -uNr log.before log.after > --- log.before 2026-03-12 14:19:04.119957887 +0800 > +++ log.after 2026-03-12 14:23:03.468251328 +0800 > @@ -26,7 +26,7 @@ > #12/p Dest pointer in r0 - succeed, check 3 OK > #13/u Dest pointer in r0 - succeed, check 4 OK > #13/p Dest pointer in r0 - succeed, check 4 OK > -#14/p Dest pointer in r0 - succeed, check 5 OK > +#14/p Dest pointer in r0 - succeed, check 5 OK (NOTE: not executed due to > unknown alignment) As stated in my previous answer, this note would be incorrect: the program was executed in test case #14 because it was rejected, not because of unknown alignment. [...]