From: Cupertino Miranda <cupertino.miranda@oracle.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
martin.lau@kernel.org, kernel-team@meta.com,
Emil Tsalapatis <emil@etsalapatis.com>
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: add test for LDX/STX/ST relocations over array field
Date: Tue, 11 Feb 2025 10:27:13 +0000 [thread overview]
Message-ID: <19509eac-c9e3-4c9a-aeaf-dda933f477cc@oracle.com> (raw)
In-Reply-To: <CAEf4BzZAOJMm7pdaM6DYn=_nhL9qA2h29V-itpQx=RvgyMsodw@mail.gmail.com>
On 11-02-2025 00:33, Andrii Nakryiko wrote:
> On Mon, Feb 10, 2025 at 12:13 PM Cupertino Miranda
> <cupertino.miranda@oracle.com> wrote:
>>
>> Hi Andrii,
>>
>> On 07-02-2025 01:48, Andrii Nakryiko wrote:
>>> Add a simple repro for the issue of miscalculating LDX/STX/ST CO-RE
>>> relocation size adjustment when the CO-RE relocation target type is an
>>> ARRAY.
>>>
>>> We need to make sure that compiler generates LDX/STX/ST instruction with
>>> CO-RE relocation against entire ARRAY type, not ARRAY's element. With
>>> the code pattern in selftest, we get this:
>>>
>>> 59: 61 71 00 00 00 00 00 00 w1 = *(u32 *)(r7 + 0x0)
>>> 00000000000001d8: CO-RE <byte_off> [5] struct core_reloc_arrays::a (0:0)
>>>
>>> Where offset of `int a[5]` is embedded (through CO-RE relocation) into memory
>>> load instruction itself.
>>>
>>> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
>>> ---
>>> tools/testing/selftests/bpf/prog_tests/core_reloc.c | 6 ++++--
>>> ...f__core_reloc_arrays___err_bad_signed_arr_elem_sz.c | 3 +++
>>> tools/testing/selftests/bpf/progs/core_reloc_types.h | 10 ++++++++++
>>> .../selftests/bpf/progs/test_core_reloc_arrays.c | 5 +++++
>>> 4 files changed, 22 insertions(+), 2 deletions(-)
>>> create mode 100644 tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_bad_signed_arr_elem_sz.c
>>>
>>> diff --git a/tools/testing/selftests/bpf/prog_tests/core_reloc.c b/tools/testing/selftests/bpf/prog_tests/core_reloc.c
>>> index e10ea92c3fe2..08963c82f30b 100644
>>> --- a/tools/testing/selftests/bpf/prog_tests/core_reloc.c
>>> +++ b/tools/testing/selftests/bpf/prog_tests/core_reloc.c
>>> @@ -85,11 +85,11 @@ static int duration = 0;
>>> #define NESTING_ERR_CASE(name) { \
>>> NESTING_CASE_COMMON(name), \
>>> .fails = true, \
>>> - .run_btfgen_fails = true, \
>>> + .run_btfgen_fails = true, \
>>> }
>>>
>>> #define ARRAYS_DATA(struct_name) STRUCT_TO_CHAR_PTR(struct_name) { \
>>> - .a = { [2] = 1 }, \
>>> + .a = { [2] = 1, [3] = 11 }, \
>>> .b = { [1] = { [2] = { [3] = 2 } } }, \
>>> .c = { [1] = { .c = 3 } }, \
>>> .d = { [0] = { [0] = { .d = 4 } } }, \
>>> @@ -108,6 +108,7 @@ static int duration = 0;
>>> .input_len = sizeof(struct core_reloc_##name), \
>>> .output = STRUCT_TO_CHAR_PTR(core_reloc_arrays_output) { \
>>> .a2 = 1, \
>>> + .a3 = 12, \
>>> .b123 = 2, \
>>> .c1c = 3, \
>>> .d00d = 4, \
>>> @@ -602,6 +603,7 @@ static const struct core_reloc_test_case test_cases[] = {
>>> ARRAYS_ERR_CASE(arrays___err_non_array),
>>> ARRAYS_ERR_CASE(arrays___err_wrong_val_type),
>>> ARRAYS_ERR_CASE(arrays___err_bad_zero_sz_arr),
>>> + ARRAYS_ERR_CASE(arrays___err_bad_signed_arr_elem_sz),
>>>
>>> /* enum/ptr/int handling scenarios */
>>> PRIMITIVES_CASE(primitives),
>>> diff --git a/tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_bad_signed_arr_elem_sz.c b/tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_bad_signed_arr_elem_sz.c
>>> new file mode 100644
>>> index 000000000000..21a560427b10
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/bpf/progs/btf__core_reloc_arrays___err_bad_signed_arr_elem_sz.c
>>> @@ -0,0 +1,3 @@
>>> +#include "core_reloc_types.h"
>>> +
>>> +void f(struct core_reloc_arrays___err_bad_signed_arr_elem_sz x) {}
>>> diff --git a/tools/testing/selftests/bpf/progs/core_reloc_types.h b/tools/testing/selftests/bpf/progs/core_reloc_types.h
>>> index fd8e1b4c6762..5760ae015e09 100644
>>> --- a/tools/testing/selftests/bpf/progs/core_reloc_types.h
>>> +++ b/tools/testing/selftests/bpf/progs/core_reloc_types.h
>>> @@ -347,6 +347,7 @@ struct core_reloc_nesting___err_too_deep {
>>> */
>>> struct core_reloc_arrays_output {
>>> int a2;
>>> + int a3;
>>> char b123;
>>> int c1c;
>>> int d00d;
>>> @@ -455,6 +456,15 @@ struct core_reloc_arrays___err_bad_zero_sz_arr {
>>> struct core_reloc_arrays_substruct d[1][2];
>>> };
>>>
>>> +struct core_reloc_arrays___err_bad_signed_arr_elem_sz {
>>> + /* int -> short (signed!): not supported case */
>>> + short a[5];
>>> + char b[2][3][4];
>>> + struct core_reloc_arrays_substruct c[3];
>>> + struct core_reloc_arrays_substruct d[1][2];
>>> + struct core_reloc_arrays_substruct f[][2];
>>> +};
>>> +
>>> /*
>>> * PRIMITIVES
>>> */
>>> diff --git a/tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c b/tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c
>>> index 51b3f79df523..448403634eea 100644
>>> --- a/tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c
>>> +++ b/tools/testing/selftests/bpf/progs/test_core_reloc_arrays.c
>>> @@ -15,6 +15,7 @@ struct {
>>>
>>> struct core_reloc_arrays_output {
>>> int a2;
>>> + int a3;
>>> char b123;
>>> int c1c;
>>> int d00d;
>>> @@ -41,6 +42,7 @@ int test_core_arrays(void *ctx)
>>> {
>>> struct core_reloc_arrays *in = (void *)&data.in;
>>> struct core_reloc_arrays_output *out = (void *)&data.out;
>>> + int *a;
>>>
>>> if (CORE_READ(&out->a2, &in->a[2]))
>>> return 1;
>>> @@ -53,6 +55,9 @@ int test_core_arrays(void *ctx)
>>> if (CORE_READ(&out->f01c, &in->f[0][1].c))
>>> return 1;
>>>
>>> + a = __builtin_preserve_access_index(({ in->a; }));
>>> + out->a3 = a[0] + a[1] + a[2] + a[3];
>> Just to try to understand what seems to be the expectation from the
>> compiler and CO-RE in this case.
>> Do you expect that all those a[n] accesses would be generating CO-RE
>> relocations assuming the size for the elements in in->a ?
>>
>
> Well, I only care to get LDX instruction with associated in->a CO-RE
> relocation. This is what Clang currently generates for this piece of
> code. You can see that it combines both LDX+CO-RE relo for a[0], and
> then non-CO-RE relocated LDX for a[1], a[2], a[3], where the base was
> relocated with CO-RE a bit earlier.
>
> 44: 18 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r7 = 0x0 ll
> 0000000000000160: R_BPF_64_64 data
>
> ...
>
> 55: b7 01 00 00 00 00 00 00 r1 = 0x0
> 00000000000001b8: CO-RE <byte_off> [5] struct
> core_reloc_arrays::a (0:0)
> 56: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0x0 ll
> 00000000000001c0: R_BPF_64_64 data
> 58: 0f 12 00 00 00 00 00 00 r2 += r1
> 59: 61 71 00 00 00 00 00 00 w1 = *(u32 *)(r7 + 0x0)
> 00000000000001d8: CO-RE <byte_off> [5] struct
> core_reloc_arrays::a (0:0)
> 60: 61 23 04 00 00 00 00 00 w3 = *(u32 *)(r2 + 0x4)
> 61: 0c 13 00 00 00 00 00 00 w3 += w1
> 62: 61 21 08 00 00 00 00 00 w1 = *(u32 *)(r2 + 0x8)
> 63: 0c 13 00 00 00 00 00 00 w3 += w1
> 64: 61 21 0c 00 00 00 00 00 w1 = *(u32 *)(r2 + 0xc)
> 65: 0c 13 00 00 00 00 00 00 w3 += w1
> 66: 63 37 04 01 00 00 00 00 *(u32 *)(r7 + 0x104) = w3
>
> Clang might change code generation pattern in the future, of course,
> but at least as of right now I know I did test this logic :) Ideally
> I'd be able to generate embedded asm with CO-RE relocation, but I'm
> not sure that's supported today.
Ok, good! I just miss read it. :)
Thanks!
>
>>> +
>>> return 0;
>>> }
>>>
>>
next prev parent reply other threads:[~2025-02-11 10:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 1:48 [PATCH bpf-next 1/2] libbpf: fix LDX/STX/ST CO-RE relocation size adjustment logic Andrii Nakryiko
2025-02-07 1:48 ` [PATCH bpf-next 2/2] selftests/bpf: add test for LDX/STX/ST relocations over array field Andrii Nakryiko
2025-02-10 20:12 ` Cupertino Miranda
2025-02-11 0:33 ` Andrii Nakryiko
2025-02-11 10:27 ` Cupertino Miranda [this message]
2025-02-07 21:45 ` [PATCH bpf-next 1/2] libbpf: fix LDX/STX/ST CO-RE relocation size adjustment logic Eduard Zingerman
2025-02-10 20:05 ` Andrii Nakryiko
2025-02-15 4:10 ` 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=19509eac-c9e3-4c9a-aeaf-dda933f477cc@oracle.com \
--to=cupertino.miranda@oracle.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=kernel-team@meta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox