From: Yonghong Song <yonghong.song@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>
Subject: Re: [PATCH bpf-next v3 2/2] selftests/bpf: Add ldsx selftests for ldsx and subreg compare
Date: Tue, 16 Jul 2024 23:06:19 -0700 [thread overview]
Message-ID: <e5cf2fb6-a0a9-4224-b709-5ba6be7537e3@linux.dev> (raw)
In-Reply-To: <9f7470ba841548b6d534b3886d8c76c4352323e0.camel@gmail.com>
On 7/16/24 5:12 PM, Eduard Zingerman wrote:
> On Tue, 2024-07-16 at 15:38 -0700, Yonghong Song wrote:
>
> [...]
>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/reg_bounds.c b/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
>> index eb74363f9f70..c88602908cfe 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
>> @@ -441,6 +441,22 @@ static struct range range_refine(enum num_t x_t, struct range x, enum num_t y_t,
>> if (t_is_32(y_t) && !t_is_32(x_t)) {
>> struct range x_swap;
>>
>> + /* If we know that
>> + * - *x* is in the range of signed 32bit value
>> + * - *y_cast* range is 32-bit sign non-negative, and
>> + * then *x* range can be narrowed to the interaction of
>> + * *x* and *y_cast*. Otherwise, if the new range for *x*
>> + * allows upper 32-bit 0xffffffff then the eventual new
>> + * range for *x* will be out of signed 32-bit range
>> + * which violates the origin *x* range.
>> + */
>> + if (x_t == S64 && y_t == S32 &&
>> + !(y_cast.a & 0xffffffff80000000ULL) && !(y_cast.b & 0xffffffff80000000) &&
>> + (long long)x.a >= S32_MIN && (long long)x.b <= S32_MAX) {
>> + return range(S64, max_t(S64, y_cast.a, x.a),
>> + min_t(S64, y_cast.b, x.b));
>> + }
>> +
>> /* some combinations of upper 32 bits and sign bit can lead to
>> * invalid ranges, in such cases it's easier to detect them
>> * after cast/swap than try to enumerate all the conditions
>> @@ -2108,6 +2124,9 @@ static struct subtest_case crafted_cases[] = {
>> {S32, U32, {(u32)S32_MIN, 0}, {0, 0}},
>> {S32, U32, {(u32)S32_MIN, 0}, {(u32)S32_MIN, (u32)S32_MIN}},
>> {S32, U32, {(u32)S32_MIN, S32_MAX}, {S32_MAX, S32_MAX}},
>> + {S64, U32, {0x0, 0x1f}, {0xffffffff80000000ULL, 0x000000007fffffffULL}},
>> + {S64, U32, {0x0, 0x1f}, {0xffffffffffff8000ULL, 0x0000000000007fffULL}},
>> + {S64, U32, {0x0, 0x1f}, {0xffffffffffffff80ULL, 0x000000000000007fULL}},
>> };
>>
>> /* Go over crafted hard-coded cases. This is fast, so we do it as part of
>>
>> The logic is very similar to kernel implementation but has a difference in generating
>> the final range. In reg_bounds implementation, the range is narrowed by intersecting
>> y_cast and x range which are necessary.
>>
>> In kernel implementation, there is no interection since we only have one register
>> and two register has been compared before.
>>
>> Eduard, could you take a look at the above code?
> I think this change is correct.
> The return clause could be simplified a bit:
>
> return range_improve(x_t, x, y_cast);
Indeed. This is much simpler. I will use reg_bounds testing instead of verifier_ldsx testing
in next revision.
>
> [...]
next prev parent reply other threads:[~2024-07-17 6:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 23:43 [PATCH bpf-next v3 1/2] bpf: Get better reg range with ldsx and 32bit compare Yonghong Song
2024-07-12 23:44 ` [PATCH bpf-next v3 2/2] selftests/bpf: Add ldsx selftests for ldsx and subreg compare Yonghong Song
2024-07-16 0:44 ` Eduard Zingerman
2024-07-16 22:38 ` Yonghong Song
2024-07-17 0:12 ` Eduard Zingerman
2024-07-17 6:06 ` Yonghong Song [this message]
2024-07-15 23:55 ` [PATCH bpf-next v3 1/2] bpf: Get better reg range with ldsx and 32bit compare Eduard Zingerman
2024-07-17 7:27 ` Shung-Hsi Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e5cf2fb6-a0a9-4224-b709-5ba6be7537e3@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.