From: Yonghong Song <yonghong.song@linux.dev>
To: Martin KaFai Lau <martin.lau@linux.dev>
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>,
bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 3/3] selftests/bpf: Fix test dynptr/test_dynptr_memset_xdp_chunks failure
Date: Fri, 25 Jul 2025 17:59:03 -0700 [thread overview]
Message-ID: <74ad40ee-1a78-4a0d-8408-ff22defb632b@linux.dev> (raw)
In-Reply-To: <3c145192-122d-46fc-8567-be30a2694a4d@linux.dev>
On 7/25/25 4:29 PM, Martin KaFai Lau wrote:
> On 7/24/25 9:34 PM, Yonghong Song wrote:
>> For arm64 64K page size, the xdp data size was set to be more than 64K
>> in one of previous patches. This will cause failure for
>> bpf_dynptr_memset().
>> Since the failure of bpf_dynptr_memset() is expected with 64K page size,
>> return success.
>>
>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>> ---
>> tools/testing/selftests/bpf/progs/dynptr_success.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/bpf/progs/dynptr_success.c
>> b/tools/testing/selftests/bpf/progs/dynptr_success.c
>> index 3094a1e4ee91..8315273cb900 100644
>> --- a/tools/testing/selftests/bpf/progs/dynptr_success.c
>> +++ b/tools/testing/selftests/bpf/progs/dynptr_success.c
>> @@ -9,6 +9,8 @@
>> #include "bpf_misc.h"
>> #include "errno.h"
>> +#define PAGE_SIZE_64K 65536
>> +
>> char _license[] SEC("license") = "GPL";
>> int pid, err, val;
>> @@ -821,8 +823,17 @@ int test_dynptr_memset_xdp_chunks(struct xdp_md
>> *xdp)
>> data_sz = bpf_dynptr_size(&ptr_xdp);
>> err = bpf_dynptr_memset(&ptr_xdp, 0, data_sz,
>> DYNPTR_MEMSET_VAL);
>> - if (err)
>> + if (err) {
>> + /* bpf_dynptr_memset() eventually called bpf_xdp_pointer()
>
> I don't think I understand why the test fixed in patch 1 (e.g.
> test_probe_read_user_dynptr) can pass the bpf_xdp_pointer test on
> 0xffff. I thought the bpf_probe_read_user_str_dynptr will eventually
> call the __bpf_xdp_store_bytes which also does a bpf_xdp_pointer?
For example, for test_probe_read_user_dynptr, for function test_dynptr_probe_xdp(),
for this one:
off = xdp_near_frag_end_offset();
the off = 64928. Note that xdp_near_frag_end_offset() return value depends page size.
__u32 xdp_near_frag_end_offset(void)
{
const __u32 headroom = 256;
const __u32 max_frag_size = __PAGE_SIZE - headroom - sizeof(struct skb_shared_info);
/* 32 bytes before the approximate end of the fragment */
return max_frag_size - 32;
}
The 'len' depends on 'test_len[i]' and test_len is
__u32 test_len[7] = {0/* placeholder */, 0, 1, 2, 255, 256, 257};
In bpf_xdp_pointer, we have the following test
if (unlikely(offset > 0xffff || len > 0xffff))
return ERR_PTR(-EFAULT);
In this particular case, offset = 64928, len = {0, 1, 2, 255, 256, 257}, so
it won't return -EFAULT.
For this patch 3, test_dynptr_memset_xdp_chunks, eventually we reached here:
for (write_off = 0; write_off < size; write_off += chunk_sz) {
chunk_sz = min_t(u32, sizeof(buf), size - write_off);
err = __bpf_dynptr_write(ptr, offset + write_off, buf, chunk_sz, 0);
if (err)
return err;
}
So the 'size' is 90000, chunk_sz is 256.
So 'offset + write_off' will be 0, 256, 512, ..., 65536
Once it reached 65536, 'offset > 0xffff' will become true since 0xffff = 65535.
and the -EFAULT will be returned.
>
>> + * where if data_sz is greater than 0xffff, -EFAULT will be
>> + * returned. For 64K page size, data_sz is greater than
>> + * 64K, so error is expected and let us zero out error and
>> + * return success.
>> + */
>> + if (data_sz >= PAGE_SIZE_64K)
>> + err = 0;
>> goto out;
>> + }
>> bpf_for(i, 0, max_chunks) {
>> offset = i * sizeof(buf);
>
next prev parent reply other threads:[~2025-07-26 0:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 4:34 [PATCH bpf-next 0/3] selftests/bpf: Fix a few dynptr test failures with 64K page size Yonghong Song
2025-07-25 4:34 ` [PATCH bpf-next 1/3] selftests/bpf: Increase xdp data size for arm64 " Yonghong Song
2025-07-25 11:53 ` Mykyta Yatsenko
2025-07-25 4:34 ` [PATCH bpf-next 2/3] selftests/bpf: Fix test dynptr/test_dynptr_copy_xdp failure Yonghong Song
2025-07-25 11:53 ` Mykyta Yatsenko
2025-07-25 4:34 ` [PATCH bpf-next 3/3] selftests/bpf: Fix test dynptr/test_dynptr_memset_xdp_chunks failure Yonghong Song
2025-07-25 23:29 ` Martin KaFai Lau
2025-07-26 0:59 ` Yonghong Song [this message]
2025-07-26 1:41 ` Martin KaFai Lau
2025-07-26 1:40 ` [PATCH bpf-next 0/3] selftests/bpf: Fix a few dynptr test failures with 64K page size patchwork-bot+netdevbpf
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=74ad40ee-1a78-4a0d-8408-ff22defb632b@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=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
/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.