* [PATCH -next 0/2] Support riscv jit to provide bpf_line_info @ 2022-04-26 14:09 Pu Lehui 2022-04-26 14:09 ` [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo Pu Lehui 2022-04-26 14:09 ` [PATCH -next 2/2] riscv, bpf: Support riscv jit to provide bpf_line_info Pu Lehui 0 siblings, 2 replies; 7+ messages in thread From: Pu Lehui @ 2022-04-26 14:09 UTC (permalink / raw) To: bpf, linux-riscv, netdev, linux-kernel Cc: bjorn, luke.r.nels, xi.wang, ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend, kpsingh, paul.walmsley, palmer, aou, pulehui patch 1 fix an issue that could not print bpf line info due to data inconsistency in 32-bit environment. patch 2 add support for riscv jit to provide bpf_line_info. Both RV32 and RV64 tests have been passed as like follow: ./test_progs -a btf #19 btf:OK Summary: 1/215 PASSED, 0 SKIPPED, 0 FAILED Pu Lehui (2): bpf: Unify data extension operation of jited_ksyms and jited_linfo riscv, bpf: Support riscv jit to provide bpf_line_info arch/riscv/net/bpf_jit.h | 1 + arch/riscv/net/bpf_jit_core.c | 7 ++++++- kernel/bpf/syscall.c | 5 ++++- tools/lib/bpf/bpf_prog_linfo.c | 8 ++++---- tools/testing/selftests/bpf/prog_tests/btf.c | 18 +++++++++--------- 5 files changed, 24 insertions(+), 15 deletions(-) -- 2.25.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo 2022-04-26 14:09 [PATCH -next 0/2] Support riscv jit to provide bpf_line_info Pu Lehui @ 2022-04-26 14:09 ` Pu Lehui 2022-04-27 22:33 ` Andrii Nakryiko 2022-04-26 14:09 ` [PATCH -next 2/2] riscv, bpf: Support riscv jit to provide bpf_line_info Pu Lehui 1 sibling, 1 reply; 7+ messages in thread From: Pu Lehui @ 2022-04-26 14:09 UTC (permalink / raw) To: bpf, linux-riscv, netdev, linux-kernel Cc: bjorn, luke.r.nels, xi.wang, ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend, kpsingh, paul.walmsley, palmer, aou, pulehui We found that 32-bit environment can not print bpf line info due to data inconsistency between jited_ksyms[0] and jited_linfo[0]. For example: jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c We know that both of them store bpf func address, but due to the different data extension operations when extended to u64, they may not be the same. We need to unify the data extension operations of them. Signed-off-by: Pu Lehui <pulehui@huawei.com> --- kernel/bpf/syscall.c | 5 ++++- tools/lib/bpf/bpf_prog_linfo.c | 8 ++++---- tools/testing/selftests/bpf/prog_tests/btf.c | 18 +++++++++--------- 3 files changed, 17 insertions(+), 14 deletions(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index e9621cfa09f2..4c417c806d92 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -3868,13 +3868,16 @@ static int bpf_prog_get_info_by_fd(struct file *file, info.nr_jited_line_info = 0; if (info.nr_jited_line_info && ulen) { if (bpf_dump_raw_ok(file->f_cred)) { + unsigned long jited_linfo_addr; __u64 __user *user_linfo; u32 i; user_linfo = u64_to_user_ptr(info.jited_line_info); ulen = min_t(u32, info.nr_jited_line_info, ulen); for (i = 0; i < ulen; i++) { - if (put_user((__u64)(long)prog->aux->jited_linfo[i], + jited_linfo_addr = (unsigned long) + prog->aux->jited_linfo[i]; + if (put_user((__u64) jited_linfo_addr, &user_linfo[i])) return -EFAULT; } diff --git a/tools/lib/bpf/bpf_prog_linfo.c b/tools/lib/bpf/bpf_prog_linfo.c index 5c503096ef43..5cf41a563ef5 100644 --- a/tools/lib/bpf/bpf_prog_linfo.c +++ b/tools/lib/bpf/bpf_prog_linfo.c @@ -127,7 +127,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) prog_linfo->raw_linfo = malloc(data_sz); if (!prog_linfo->raw_linfo) goto err_free; - memcpy(prog_linfo->raw_linfo, (void *)(long)info->line_info, data_sz); + memcpy(prog_linfo->raw_linfo, (void *)(unsigned long)info->line_info, data_sz); nr_jited_func = info->nr_jited_ksyms; if (!nr_jited_func || @@ -148,7 +148,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) if (!prog_linfo->raw_jited_linfo) goto err_free; memcpy(prog_linfo->raw_jited_linfo, - (void *)(long)info->jited_line_info, data_sz); + (void *)(unsigned long)info->jited_line_info, data_sz); /* Number of jited_line_info per jited func */ prog_linfo->nr_jited_linfo_per_func = malloc(nr_jited_func * @@ -166,8 +166,8 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) goto err_free; if (dissect_jited_func(prog_linfo, - (__u64 *)(long)info->jited_ksyms, - (__u32 *)(long)info->jited_func_lens)) + (__u64 *)(unsigned long)info->jited_ksyms, + (__u32 *)(unsigned long)info->jited_func_lens)) goto err_free; return prog_linfo; diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c index 84aae639ddb5..d9ba1ec1d5b3 100644 --- a/tools/testing/selftests/bpf/prog_tests/btf.c +++ b/tools/testing/selftests/bpf/prog_tests/btf.c @@ -6451,8 +6451,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, info.nr_jited_line_info, jited_cnt, info.line_info_rec_size, rec_size, info.jited_line_info_rec_size, jited_rec_size, - (void *)(long)info.line_info, - (void *)(long)info.jited_line_info)) { + (void *)(unsigned long)info.line_info, + (void *)(unsigned long)info.jited_line_info)) { err = -1; goto done; } @@ -6500,8 +6500,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, } if (CHECK(jited_linfo[0] != jited_ksyms[0], - "jited_linfo[0]:%lx != jited_ksyms[0]:%lx", - (long)(jited_linfo[0]), (long)(jited_ksyms[0]))) { + "jited_linfo[0]:%llx != jited_ksyms[0]:%llx", + jited_linfo[0], jited_ksyms[0])) { err = -1; goto done; } @@ -6519,16 +6519,16 @@ static int test_get_linfo(const struct prog_info_raw_test *test, } if (CHECK(jited_linfo[i] <= jited_linfo[i - 1], - "jited_linfo[%u]:%lx <= jited_linfo[%u]:%lx", - i, (long)jited_linfo[i], - i - 1, (long)(jited_linfo[i - 1]))) { + "jited_linfo[%u]:%llx <= jited_linfo[%u]:%llx", + i, jited_linfo[i], + i - 1, (jited_linfo[i - 1]))) { err = -1; goto done; } if (CHECK(jited_linfo[i] - cur_func_ksyms > cur_func_len, - "jited_linfo[%u]:%lx - %lx > %u", - i, (long)jited_linfo[i], (long)cur_func_ksyms, + "jited_linfo[%u]:%llx - %llx > %u", + i, jited_linfo[i], cur_func_ksyms, cur_func_len)) { err = -1; goto done; -- 2.25.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo 2022-04-26 14:09 ` [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo Pu Lehui @ 2022-04-27 22:33 ` Andrii Nakryiko 2022-04-28 9:47 ` Pu Lehui 0 siblings, 1 reply; 7+ messages in thread From: Andrii Nakryiko @ 2022-04-27 22:33 UTC (permalink / raw) To: Pu Lehui Cc: bpf, linux-riscv, Networking, open list, Björn Töpel, Luke Nelson, Xi Wang, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin Lau, Song Liu, Yonghong Song, john fastabend, KP Singh, Paul Walmsley, Palmer Dabbelt, Albert Ou On Tue, Apr 26, 2022 at 6:40 AM Pu Lehui <pulehui@huawei.com> wrote: > > We found that 32-bit environment can not print bpf line info due > to data inconsistency between jited_ksyms[0] and jited_linfo[0]. > > For example: > jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c > > We know that both of them store bpf func address, but due to the > different data extension operations when extended to u64, they may > not be the same. We need to unify the data extension operations of > them. > > Signed-off-by: Pu Lehui <pulehui@huawei.com> > --- > kernel/bpf/syscall.c | 5 ++++- > tools/lib/bpf/bpf_prog_linfo.c | 8 ++++---- > tools/testing/selftests/bpf/prog_tests/btf.c | 18 +++++++++--------- please split kernel changes, libbpf changes, and selftests/bpf changes into separate patches > 3 files changed, 17 insertions(+), 14 deletions(-) > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > index e9621cfa09f2..4c417c806d92 100644 > --- a/kernel/bpf/syscall.c > +++ b/kernel/bpf/syscall.c > @@ -3868,13 +3868,16 @@ static int bpf_prog_get_info_by_fd(struct file *file, > info.nr_jited_line_info = 0; > if (info.nr_jited_line_info && ulen) { > if (bpf_dump_raw_ok(file->f_cred)) { > + unsigned long jited_linfo_addr; > __u64 __user *user_linfo; > u32 i; > > user_linfo = u64_to_user_ptr(info.jited_line_info); > ulen = min_t(u32, info.nr_jited_line_info, ulen); > for (i = 0; i < ulen; i++) { > - if (put_user((__u64)(long)prog->aux->jited_linfo[i], > + jited_linfo_addr = (unsigned long) > + prog->aux->jited_linfo[i]; > + if (put_user((__u64) jited_linfo_addr, > &user_linfo[i])) > return -EFAULT; > } > diff --git a/tools/lib/bpf/bpf_prog_linfo.c b/tools/lib/bpf/bpf_prog_linfo.c > index 5c503096ef43..5cf41a563ef5 100644 > --- a/tools/lib/bpf/bpf_prog_linfo.c > +++ b/tools/lib/bpf/bpf_prog_linfo.c > @@ -127,7 +127,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) > prog_linfo->raw_linfo = malloc(data_sz); > if (!prog_linfo->raw_linfo) > goto err_free; > - memcpy(prog_linfo->raw_linfo, (void *)(long)info->line_info, data_sz); > + memcpy(prog_linfo->raw_linfo, (void *)(unsigned long)info->line_info, data_sz); > > nr_jited_func = info->nr_jited_ksyms; > if (!nr_jited_func || > @@ -148,7 +148,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) > if (!prog_linfo->raw_jited_linfo) > goto err_free; > memcpy(prog_linfo->raw_jited_linfo, > - (void *)(long)info->jited_line_info, data_sz); > + (void *)(unsigned long)info->jited_line_info, data_sz); > > /* Number of jited_line_info per jited func */ > prog_linfo->nr_jited_linfo_per_func = malloc(nr_jited_func * > @@ -166,8 +166,8 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) > goto err_free; > > if (dissect_jited_func(prog_linfo, > - (__u64 *)(long)info->jited_ksyms, > - (__u32 *)(long)info->jited_func_lens)) > + (__u64 *)(unsigned long)info->jited_ksyms, > + (__u32 *)(unsigned long)info->jited_func_lens)) so I'm trying to understand how this is changing anything for 32-bit architecture and I must be missing something, sorry if I'm being dense. The example you used below jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c Wouldn't (unsigned long)0xffffffffb800067c == (long)0xffffffffb800067c == 0xb800067c ? isn't sizeof(long) == sizeof(void*) == 4? It would be nice if you could elaborate a bit more on what problems did you see in practice? > goto err_free; > > return prog_linfo; > diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c > index 84aae639ddb5..d9ba1ec1d5b3 100644 > --- a/tools/testing/selftests/bpf/prog_tests/btf.c > +++ b/tools/testing/selftests/bpf/prog_tests/btf.c > @@ -6451,8 +6451,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, > info.nr_jited_line_info, jited_cnt, > info.line_info_rec_size, rec_size, > info.jited_line_info_rec_size, jited_rec_size, > - (void *)(long)info.line_info, > - (void *)(long)info.jited_line_info)) { > + (void *)(unsigned long)info.line_info, > + (void *)(unsigned long)info.jited_line_info)) { > err = -1; > goto done; > } > @@ -6500,8 +6500,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, > } > > if (CHECK(jited_linfo[0] != jited_ksyms[0], > - "jited_linfo[0]:%lx != jited_ksyms[0]:%lx", > - (long)(jited_linfo[0]), (long)(jited_ksyms[0]))) { > + "jited_linfo[0]:%llx != jited_ksyms[0]:%llx", > + jited_linfo[0], jited_ksyms[0])) { > err = -1; > goto done; > } > @@ -6519,16 +6519,16 @@ static int test_get_linfo(const struct prog_info_raw_test *test, > } > > if (CHECK(jited_linfo[i] <= jited_linfo[i - 1], > - "jited_linfo[%u]:%lx <= jited_linfo[%u]:%lx", > - i, (long)jited_linfo[i], > - i - 1, (long)(jited_linfo[i - 1]))) { > + "jited_linfo[%u]:%llx <= jited_linfo[%u]:%llx", > + i, jited_linfo[i], > + i - 1, (jited_linfo[i - 1]))) { > err = -1; > goto done; > } > > if (CHECK(jited_linfo[i] - cur_func_ksyms > cur_func_len, > - "jited_linfo[%u]:%lx - %lx > %u", > - i, (long)jited_linfo[i], (long)cur_func_ksyms, > + "jited_linfo[%u]:%llx - %llx > %u", > + i, jited_linfo[i], cur_func_ksyms, > cur_func_len)) { > err = -1; > goto done; > -- > 2.25.1 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo 2022-04-27 22:33 ` Andrii Nakryiko @ 2022-04-28 9:47 ` Pu Lehui 2022-05-06 21:01 ` Andrii Nakryiko 0 siblings, 1 reply; 7+ messages in thread From: Pu Lehui @ 2022-04-28 9:47 UTC (permalink / raw) To: Andrii Nakryiko Cc: bpf, linux-riscv, Networking, open list, Björn Töpel, Luke Nelson, Xi Wang, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin Lau, Song Liu, Yonghong Song, john fastabend, KP Singh, Paul Walmsley, Palmer Dabbelt, Albert Ou Hi Andrii, On 2022/4/28 6:33, Andrii Nakryiko wrote: > On Tue, Apr 26, 2022 at 6:40 AM Pu Lehui <pulehui@huawei.com> wrote: >> >> We found that 32-bit environment can not print bpf line info due >> to data inconsistency between jited_ksyms[0] and jited_linfo[0]. >> >> For example: >> jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c >> >> We know that both of them store bpf func address, but due to the >> different data extension operations when extended to u64, they may >> not be the same. We need to unify the data extension operations of >> them. >> >> Signed-off-by: Pu Lehui <pulehui@huawei.com> >> --- >> kernel/bpf/syscall.c | 5 ++++- >> tools/lib/bpf/bpf_prog_linfo.c | 8 ++++---- >> tools/testing/selftests/bpf/prog_tests/btf.c | 18 +++++++++--------- > > please split kernel changes, libbpf changes, and selftests/bpf changes > into separate patches Thanks for your review. Alright, I will split it next time. > >> 3 files changed, 17 insertions(+), 14 deletions(-) >> >> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c >> index e9621cfa09f2..4c417c806d92 100644 >> --- a/kernel/bpf/syscall.c >> +++ b/kernel/bpf/syscall.c >> @@ -3868,13 +3868,16 @@ static int bpf_prog_get_info_by_fd(struct file *file, >> info.nr_jited_line_info = 0; >> if (info.nr_jited_line_info && ulen) { >> if (bpf_dump_raw_ok(file->f_cred)) { >> + unsigned long jited_linfo_addr; >> __u64 __user *user_linfo; >> u32 i; >> >> user_linfo = u64_to_user_ptr(info.jited_line_info); >> ulen = min_t(u32, info.nr_jited_line_info, ulen); >> for (i = 0; i < ulen; i++) { >> - if (put_user((__u64)(long)prog->aux->jited_linfo[i], >> + jited_linfo_addr = (unsigned long) >> + prog->aux->jited_linfo[i]; >> + if (put_user((__u64) jited_linfo_addr, >> &user_linfo[i])) >> return -EFAULT; >> } Please let me to explain more detail, sorry if I'm wordy. The main reason that 32-bit env does not print bpf line info is here: kernel/bpf/syscall.c: bpf_prog_get_info_by_fd { ... user_ksyms = u64_to_user_ptr(info.jited_ksyms); ksym_addr = (unsigned long)prog->aux->func[i]->bpf_func; if (put_user((u64) ksym_addr, &user_ksyms[i])) ... user_linfo = u64_to_user_ptr(info.jited_line_info); if (put_user((__u64)(long)prog->aux->jited_linfo[i], &user_linfo[i])) ... } In 32-bit env, ksym_addr and prog->aux->jited_linfo[0] both store the 32-bit address of bpf_func, but the first one is zero-extension to u64, while the other is sign-extension to u64. For example: prog->aux->func[0]->bpf_func = 0xb800067c user_ksyms[0] = 0xb800067c, user_linfo[0] = 0xffffffffb800067c Both zero-extension and sign-extension are fine, but if operating directly between them without casting in 32-bit env, there will have some potential problems. Such as: tools/lib/bpf/bpf_prog_linfo.c: dissect_jited_func { ... if (ksym_func[0] != *jited_linfo) //always missmatch in 32 env goto errout; ... if (ksym_func[f] == *jited_linfo) { ... last_jited_linfo = *jited_linfo; if (last_jited_linfo - ksym_func[f - 1] + 1 > ksym_len[f - 1]) ... } We could cast them to 32-bit data type, but I think unify data extension operation will be better. >> diff --git a/tools/lib/bpf/bpf_prog_linfo.c b/tools/lib/bpf/bpf_prog_linfo.c >> index 5c503096ef43..5cf41a563ef5 100644 >> --- a/tools/lib/bpf/bpf_prog_linfo.c >> +++ b/tools/lib/bpf/bpf_prog_linfo.c >> @@ -127,7 +127,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) >> prog_linfo->raw_linfo = malloc(data_sz); >> if (!prog_linfo->raw_linfo) >> goto err_free; >> - memcpy(prog_linfo->raw_linfo, (void *)(long)info->line_info, data_sz); >> + memcpy(prog_linfo->raw_linfo, (void *)(unsigned long)info->line_info, data_sz); >> >> nr_jited_func = info->nr_jited_ksyms; >> if (!nr_jited_func || >> @@ -148,7 +148,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) >> if (!prog_linfo->raw_jited_linfo) >> goto err_free; >> memcpy(prog_linfo->raw_jited_linfo, >> - (void *)(long)info->jited_line_info, data_sz); >> + (void *)(unsigned long)info->jited_line_info, data_sz); >> >> /* Number of jited_line_info per jited func */ >> prog_linfo->nr_jited_linfo_per_func = malloc(nr_jited_func * >> @@ -166,8 +166,8 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) >> goto err_free; >> >> if (dissect_jited_func(prog_linfo, >> - (__u64 *)(long)info->jited_ksyms, >> - (__u32 *)(long)info->jited_func_lens)) >> + (__u64 *)(unsigned long)info->jited_ksyms, >> + (__u32 *)(unsigned long)info->jited_func_lens)) > > so I'm trying to understand how this is changing anything for 32-bit > architecture and I must be missing something, sorry if I'm being > dense. The example you used below > > jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c > > Wouldn't (unsigned long)0xffffffffb800067c == (long)0xffffffffb800067c > == 0xb800067c ? If I understand correctly, info->jited_ksyms or info->jited_func_lens is just a u64 address that point to the corresponding space. The bpf_func address is stored in the item of info->jited_ksyms but not info->jited_ksyms. And here, I may have misled you. Both (__u64 *)(long)info->jited_ksyms and (__u64 *)(unsigned long)info->jited_ksyms are the same, I just want to unify the style. I will remove them in v2. Please let me know if there is any problem with my understanding. Thanks, Lehui > > isn't sizeof(long) == sizeof(void*) == 4? > > It would be nice if you could elaborate a bit more on what problems > did you see in practice? > >> goto err_free; >> >> return prog_linfo; >> diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c >> index 84aae639ddb5..d9ba1ec1d5b3 100644 >> --- a/tools/testing/selftests/bpf/prog_tests/btf.c >> +++ b/tools/testing/selftests/bpf/prog_tests/btf.c >> @@ -6451,8 +6451,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, >> info.nr_jited_line_info, jited_cnt, >> info.line_info_rec_size, rec_size, >> info.jited_line_info_rec_size, jited_rec_size, >> - (void *)(long)info.line_info, >> - (void *)(long)info.jited_line_info)) { >> + (void *)(unsigned long)info.line_info, >> + (void *)(unsigned long)info.jited_line_info)) { >> err = -1; >> goto done; >> } >> @@ -6500,8 +6500,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, >> } >> >> if (CHECK(jited_linfo[0] != jited_ksyms[0], >> - "jited_linfo[0]:%lx != jited_ksyms[0]:%lx", >> - (long)(jited_linfo[0]), (long)(jited_ksyms[0]))) { >> + "jited_linfo[0]:%llx != jited_ksyms[0]:%llx", >> + jited_linfo[0], jited_ksyms[0])) { >> err = -1; >> goto done; >> } >> @@ -6519,16 +6519,16 @@ static int test_get_linfo(const struct prog_info_raw_test *test, >> } >> >> if (CHECK(jited_linfo[i] <= jited_linfo[i - 1], >> - "jited_linfo[%u]:%lx <= jited_linfo[%u]:%lx", >> - i, (long)jited_linfo[i], >> - i - 1, (long)(jited_linfo[i - 1]))) { >> + "jited_linfo[%u]:%llx <= jited_linfo[%u]:%llx", >> + i, jited_linfo[i], >> + i - 1, (jited_linfo[i - 1]))) { >> err = -1; >> goto done; >> } >> >> if (CHECK(jited_linfo[i] - cur_func_ksyms > cur_func_len, >> - "jited_linfo[%u]:%lx - %lx > %u", >> - i, (long)jited_linfo[i], (long)cur_func_ksyms, >> + "jited_linfo[%u]:%llx - %llx > %u", >> + i, jited_linfo[i], cur_func_ksyms, >> cur_func_len)) { >> err = -1; >> goto done; >> -- >> 2.25.1 >> > . > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo 2022-04-28 9:47 ` Pu Lehui @ 2022-05-06 21:01 ` Andrii Nakryiko 2022-05-07 0:48 ` Pu Lehui 0 siblings, 1 reply; 7+ messages in thread From: Andrii Nakryiko @ 2022-05-06 21:01 UTC (permalink / raw) To: Pu Lehui Cc: bpf, linux-riscv, Networking, open list, Björn Töpel, Luke Nelson, Xi Wang, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin Lau, Song Liu, Yonghong Song, john fastabend, KP Singh, Paul Walmsley, Palmer Dabbelt, Albert Ou On Thu, Apr 28, 2022 at 2:47 AM Pu Lehui <pulehui@huawei.com> wrote: > > Hi Andrii, > > On 2022/4/28 6:33, Andrii Nakryiko wrote: > > On Tue, Apr 26, 2022 at 6:40 AM Pu Lehui <pulehui@huawei.com> wrote: > >> > >> We found that 32-bit environment can not print bpf line info due > >> to data inconsistency between jited_ksyms[0] and jited_linfo[0]. > >> > >> For example: > >> jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c > >> > >> We know that both of them store bpf func address, but due to the > >> different data extension operations when extended to u64, they may > >> not be the same. We need to unify the data extension operations of > >> them. > >> > >> Signed-off-by: Pu Lehui <pulehui@huawei.com> > >> --- > >> kernel/bpf/syscall.c | 5 ++++- > >> tools/lib/bpf/bpf_prog_linfo.c | 8 ++++---- > >> tools/testing/selftests/bpf/prog_tests/btf.c | 18 +++++++++--------- > > > > please split kernel changes, libbpf changes, and selftests/bpf changes > > into separate patches > Thanks for your review. Alright, I will split it next time. > > > > >> 3 files changed, 17 insertions(+), 14 deletions(-) > >> > >> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > >> index e9621cfa09f2..4c417c806d92 100644 > >> --- a/kernel/bpf/syscall.c > >> +++ b/kernel/bpf/syscall.c > >> @@ -3868,13 +3868,16 @@ static int bpf_prog_get_info_by_fd(struct file *file, > >> info.nr_jited_line_info = 0; > >> if (info.nr_jited_line_info && ulen) { > >> if (bpf_dump_raw_ok(file->f_cred)) { > >> + unsigned long jited_linfo_addr; > >> __u64 __user *user_linfo; > >> u32 i; > >> > >> user_linfo = u64_to_user_ptr(info.jited_line_info); > >> ulen = min_t(u32, info.nr_jited_line_info, ulen); > >> for (i = 0; i < ulen; i++) { > >> - if (put_user((__u64)(long)prog->aux->jited_linfo[i], > >> + jited_linfo_addr = (unsigned long) > >> + prog->aux->jited_linfo[i]; > >> + if (put_user((__u64) jited_linfo_addr, > >> &user_linfo[i])) > >> return -EFAULT; > >> } > Please let me to explain more detail, sorry if I'm wordy. > The main reason that 32-bit env does not print bpf line info is here: > > kernel/bpf/syscall.c: > bpf_prog_get_info_by_fd { > ... > user_ksyms = u64_to_user_ptr(info.jited_ksyms); > ksym_addr = (unsigned long)prog->aux->func[i]->bpf_func; > if (put_user((u64) ksym_addr, &user_ksyms[i])) > ... > > user_linfo = u64_to_user_ptr(info.jited_line_info); > if (put_user((__u64)(long)prog->aux->jited_linfo[i], > &user_linfo[i])) > ... > } > > In 32-bit env, ksym_addr and prog->aux->jited_linfo[0] both store the > 32-bit address of bpf_func, but the first one is zero-extension to u64, > while the other is sign-extension to u64. > For example: > prog->aux->func[0]->bpf_func = 0xb800067c > user_ksyms[0] = 0xb800067c, user_linfo[0] = 0xffffffffb800067c > > Both zero-extension and sign-extension are fine, but if operating > directly between them without casting in 32-bit env, there will have > some potential problems. Such as: > > tools/lib/bpf/bpf_prog_linfo.c: > dissect_jited_func { > ... > if (ksym_func[0] != *jited_linfo) //always missmatch in 32 env > goto errout; > ... > if (ksym_func[f] == *jited_linfo) { > ... > last_jited_linfo = *jited_linfo; > if (last_jited_linfo - ksym_func[f - 1] + 1 > > ksym_len[f - 1]) > ... > } > > We could cast them to 32-bit data type, but I think unify data extension > operation will be better. > > >> diff --git a/tools/lib/bpf/bpf_prog_linfo.c b/tools/lib/bpf/bpf_prog_linfo.c > >> index 5c503096ef43..5cf41a563ef5 100644 > >> --- a/tools/lib/bpf/bpf_prog_linfo.c > >> +++ b/tools/lib/bpf/bpf_prog_linfo.c > >> @@ -127,7 +127,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) > >> prog_linfo->raw_linfo = malloc(data_sz); > >> if (!prog_linfo->raw_linfo) > >> goto err_free; > >> - memcpy(prog_linfo->raw_linfo, (void *)(long)info->line_info, data_sz); > >> + memcpy(prog_linfo->raw_linfo, (void *)(unsigned long)info->line_info, data_sz); > >> > >> nr_jited_func = info->nr_jited_ksyms; > >> if (!nr_jited_func || > >> @@ -148,7 +148,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) > >> if (!prog_linfo->raw_jited_linfo) > >> goto err_free; > >> memcpy(prog_linfo->raw_jited_linfo, > >> - (void *)(long)info->jited_line_info, data_sz); > >> + (void *)(unsigned long)info->jited_line_info, data_sz); > >> > >> /* Number of jited_line_info per jited func */ > >> prog_linfo->nr_jited_linfo_per_func = malloc(nr_jited_func * > >> @@ -166,8 +166,8 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) > >> goto err_free; > >> > >> if (dissect_jited_func(prog_linfo, > >> - (__u64 *)(long)info->jited_ksyms, > >> - (__u32 *)(long)info->jited_func_lens)) > >> + (__u64 *)(unsigned long)info->jited_ksyms, > >> + (__u32 *)(unsigned long)info->jited_func_lens)) > > > > so I'm trying to understand how this is changing anything for 32-bit > > architecture and I must be missing something, sorry if I'm being > > dense. The example you used below > > > > jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c > > > > Wouldn't (unsigned long)0xffffffffb800067c == (long)0xffffffffb800067c > > == 0xb800067c ? > If I understand correctly, info->jited_ksyms or info->jited_func_lens is > just a u64 address that point to the corresponding space. The bpf_func > address is stored in the item of info->jited_ksyms but not > info->jited_ksyms. > > And here, I may have misled you. Both (__u64 *)(long)info->jited_ksyms > and (__u64 *)(unsigned long)info->jited_ksyms are the same, I just want > to unify the style. I will remove them in v2. > > Please let me know if there is any problem with my understanding. > Thanks for explanation. I guess in my mind I was always sign extending 32-bit to 64-bit, but I think memory addresses are conceptually unsigned, so (unsigned long) casting makes more sense, and u64 representation of 0xb800067c should be 0x00000000b800067c and not 0xffffffffb800067c. So your changes make sense, and I agree that libbpf-side changes for conceptual uniformity are also good. > Thanks, > Lehui > > > > isn't sizeof(long) == sizeof(void*) == 4? > > > > It would be nice if you could elaborate a bit more on what problems > > did you see in practice? > > > >> goto err_free; > >> > >> return prog_linfo; > >> diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c > >> index 84aae639ddb5..d9ba1ec1d5b3 100644 > >> --- a/tools/testing/selftests/bpf/prog_tests/btf.c > >> +++ b/tools/testing/selftests/bpf/prog_tests/btf.c > >> @@ -6451,8 +6451,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, > >> info.nr_jited_line_info, jited_cnt, > >> info.line_info_rec_size, rec_size, > >> info.jited_line_info_rec_size, jited_rec_size, > >> - (void *)(long)info.line_info, > >> - (void *)(long)info.jited_line_info)) { > >> + (void *)(unsigned long)info.line_info, > >> + (void *)(unsigned long)info.jited_line_info)) { > >> err = -1; > >> goto done; > >> } > >> @@ -6500,8 +6500,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, > >> } > >> > >> if (CHECK(jited_linfo[0] != jited_ksyms[0], > >> - "jited_linfo[0]:%lx != jited_ksyms[0]:%lx", > >> - (long)(jited_linfo[0]), (long)(jited_ksyms[0]))) { > >> + "jited_linfo[0]:%llx != jited_ksyms[0]:%llx", > >> + jited_linfo[0], jited_ksyms[0])) { > >> err = -1; > >> goto done; > >> } > >> @@ -6519,16 +6519,16 @@ static int test_get_linfo(const struct prog_info_raw_test *test, > >> } > >> > >> if (CHECK(jited_linfo[i] <= jited_linfo[i - 1], > >> - "jited_linfo[%u]:%lx <= jited_linfo[%u]:%lx", > >> - i, (long)jited_linfo[i], > >> - i - 1, (long)(jited_linfo[i - 1]))) { > >> + "jited_linfo[%u]:%llx <= jited_linfo[%u]:%llx", > >> + i, jited_linfo[i], > >> + i - 1, (jited_linfo[i - 1]))) { > >> err = -1; > >> goto done; > >> } > >> > >> if (CHECK(jited_linfo[i] - cur_func_ksyms > cur_func_len, > >> - "jited_linfo[%u]:%lx - %lx > %u", > >> - i, (long)jited_linfo[i], (long)cur_func_ksyms, > >> + "jited_linfo[%u]:%llx - %llx > %u", > >> + i, jited_linfo[i], cur_func_ksyms, > >> cur_func_len)) { > >> err = -1; > >> goto done; > >> -- > >> 2.25.1 > >> > > . > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo 2022-05-06 21:01 ` Andrii Nakryiko @ 2022-05-07 0:48 ` Pu Lehui 0 siblings, 0 replies; 7+ messages in thread From: Pu Lehui @ 2022-05-07 0:48 UTC (permalink / raw) To: Andrii Nakryiko Cc: bpf, linux-riscv, Networking, open list, Björn Töpel, Luke Nelson, Xi Wang, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin Lau, Song Liu, Yonghong Song, john fastabend, KP Singh, Paul Walmsley, Palmer Dabbelt, Albert Ou On 2022/5/7 5:01, Andrii Nakryiko wrote: > On Thu, Apr 28, 2022 at 2:47 AM Pu Lehui <pulehui@huawei.com> wrote: >> >> Hi Andrii, >> >> On 2022/4/28 6:33, Andrii Nakryiko wrote: >>> On Tue, Apr 26, 2022 at 6:40 AM Pu Lehui <pulehui@huawei.com> wrote: >>>> >>>> We found that 32-bit environment can not print bpf line info due >>>> to data inconsistency between jited_ksyms[0] and jited_linfo[0]. >>>> >>>> For example: >>>> jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c >>>> >>>> We know that both of them store bpf func address, but due to the >>>> different data extension operations when extended to u64, they may >>>> not be the same. We need to unify the data extension operations of >>>> them. >>>> >>>> Signed-off-by: Pu Lehui <pulehui@huawei.com> >>>> --- >>>> kernel/bpf/syscall.c | 5 ++++- >>>> tools/lib/bpf/bpf_prog_linfo.c | 8 ++++---- >>>> tools/testing/selftests/bpf/prog_tests/btf.c | 18 +++++++++--------- >>> >>> please split kernel changes, libbpf changes, and selftests/bpf changes >>> into separate patches >> Thanks for your review. Alright, I will split it next time. >> >>> >>>> 3 files changed, 17 insertions(+), 14 deletions(-) >>>> >>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c >>>> index e9621cfa09f2..4c417c806d92 100644 >>>> --- a/kernel/bpf/syscall.c >>>> +++ b/kernel/bpf/syscall.c >>>> @@ -3868,13 +3868,16 @@ static int bpf_prog_get_info_by_fd(struct file *file, >>>> info.nr_jited_line_info = 0; >>>> if (info.nr_jited_line_info && ulen) { >>>> if (bpf_dump_raw_ok(file->f_cred)) { >>>> + unsigned long jited_linfo_addr; >>>> __u64 __user *user_linfo; >>>> u32 i; >>>> >>>> user_linfo = u64_to_user_ptr(info.jited_line_info); >>>> ulen = min_t(u32, info.nr_jited_line_info, ulen); >>>> for (i = 0; i < ulen; i++) { >>>> - if (put_user((__u64)(long)prog->aux->jited_linfo[i], >>>> + jited_linfo_addr = (unsigned long) >>>> + prog->aux->jited_linfo[i]; >>>> + if (put_user((__u64) jited_linfo_addr, >>>> &user_linfo[i])) >>>> return -EFAULT; >>>> } >> Please let me to explain more detail, sorry if I'm wordy. >> The main reason that 32-bit env does not print bpf line info is here: >> >> kernel/bpf/syscall.c: >> bpf_prog_get_info_by_fd { >> ... >> user_ksyms = u64_to_user_ptr(info.jited_ksyms); >> ksym_addr = (unsigned long)prog->aux->func[i]->bpf_func; >> if (put_user((u64) ksym_addr, &user_ksyms[i])) >> ... >> >> user_linfo = u64_to_user_ptr(info.jited_line_info); >> if (put_user((__u64)(long)prog->aux->jited_linfo[i], >> &user_linfo[i])) >> ... >> } >> >> In 32-bit env, ksym_addr and prog->aux->jited_linfo[0] both store the >> 32-bit address of bpf_func, but the first one is zero-extension to u64, >> while the other is sign-extension to u64. >> For example: >> prog->aux->func[0]->bpf_func = 0xb800067c >> user_ksyms[0] = 0xb800067c, user_linfo[0] = 0xffffffffb800067c >> >> Both zero-extension and sign-extension are fine, but if operating >> directly between them without casting in 32-bit env, there will have >> some potential problems. Such as: >> >> tools/lib/bpf/bpf_prog_linfo.c: >> dissect_jited_func { >> ... >> if (ksym_func[0] != *jited_linfo) //always missmatch in 32 env >> goto errout; >> ... >> if (ksym_func[f] == *jited_linfo) { >> ... >> last_jited_linfo = *jited_linfo; >> if (last_jited_linfo - ksym_func[f - 1] + 1 > >> ksym_len[f - 1]) >> ... >> } >> >> We could cast them to 32-bit data type, but I think unify data extension >> operation will be better. >> >>>> diff --git a/tools/lib/bpf/bpf_prog_linfo.c b/tools/lib/bpf/bpf_prog_linfo.c >>>> index 5c503096ef43..5cf41a563ef5 100644 >>>> --- a/tools/lib/bpf/bpf_prog_linfo.c >>>> +++ b/tools/lib/bpf/bpf_prog_linfo.c >>>> @@ -127,7 +127,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) >>>> prog_linfo->raw_linfo = malloc(data_sz); >>>> if (!prog_linfo->raw_linfo) >>>> goto err_free; >>>> - memcpy(prog_linfo->raw_linfo, (void *)(long)info->line_info, data_sz); >>>> + memcpy(prog_linfo->raw_linfo, (void *)(unsigned long)info->line_info, data_sz); >>>> >>>> nr_jited_func = info->nr_jited_ksyms; >>>> if (!nr_jited_func || >>>> @@ -148,7 +148,7 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) >>>> if (!prog_linfo->raw_jited_linfo) >>>> goto err_free; >>>> memcpy(prog_linfo->raw_jited_linfo, >>>> - (void *)(long)info->jited_line_info, data_sz); >>>> + (void *)(unsigned long)info->jited_line_info, data_sz); >>>> >>>> /* Number of jited_line_info per jited func */ >>>> prog_linfo->nr_jited_linfo_per_func = malloc(nr_jited_func * >>>> @@ -166,8 +166,8 @@ struct bpf_prog_linfo *bpf_prog_linfo__new(const struct bpf_prog_info *info) >>>> goto err_free; >>>> >>>> if (dissect_jited_func(prog_linfo, >>>> - (__u64 *)(long)info->jited_ksyms, >>>> - (__u32 *)(long)info->jited_func_lens)) >>>> + (__u64 *)(unsigned long)info->jited_ksyms, >>>> + (__u32 *)(unsigned long)info->jited_func_lens)) >>> >>> so I'm trying to understand how this is changing anything for 32-bit >>> architecture and I must be missing something, sorry if I'm being >>> dense. The example you used below >>> >>> jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c >>> >>> Wouldn't (unsigned long)0xffffffffb800067c == (long)0xffffffffb800067c >>> == 0xb800067c ? >> If I understand correctly, info->jited_ksyms or info->jited_func_lens is >> just a u64 address that point to the corresponding space. The bpf_func >> address is stored in the item of info->jited_ksyms but not >> info->jited_ksyms. >> >> And here, I may have misled you. Both (__u64 *)(long)info->jited_ksyms >> and (__u64 *)(unsigned long)info->jited_ksyms are the same, I just want >> to unify the style. I will remove them in v2. >> >> Please let me know if there is any problem with my understanding. >> > > Thanks for explanation. I guess in my mind I was always sign extending > 32-bit to 64-bit, but I think memory addresses are conceptually > unsigned, so (unsigned long) casting makes more sense, and u64 > representation of 0xb800067c should be 0x00000000b800067c and not > 0xffffffffb800067c. So your changes make sense, and I agree that > libbpf-side changes for conceptual uniformity are also good. > Alright, I will pick them back in v3. Thanks. > >> Thanks, >> Lehui >>> >>> isn't sizeof(long) == sizeof(void*) == 4? >>> >>> It would be nice if you could elaborate a bit more on what problems >>> did you see in practice? >>> >>>> goto err_free; >>>> >>>> return prog_linfo; >>>> diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c >>>> index 84aae639ddb5..d9ba1ec1d5b3 100644 >>>> --- a/tools/testing/selftests/bpf/prog_tests/btf.c >>>> +++ b/tools/testing/selftests/bpf/prog_tests/btf.c >>>> @@ -6451,8 +6451,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, >>>> info.nr_jited_line_info, jited_cnt, >>>> info.line_info_rec_size, rec_size, >>>> info.jited_line_info_rec_size, jited_rec_size, >>>> - (void *)(long)info.line_info, >>>> - (void *)(long)info.jited_line_info)) { >>>> + (void *)(unsigned long)info.line_info, >>>> + (void *)(unsigned long)info.jited_line_info)) { >>>> err = -1; >>>> goto done; >>>> } >>>> @@ -6500,8 +6500,8 @@ static int test_get_linfo(const struct prog_info_raw_test *test, >>>> } >>>> >>>> if (CHECK(jited_linfo[0] != jited_ksyms[0], >>>> - "jited_linfo[0]:%lx != jited_ksyms[0]:%lx", >>>> - (long)(jited_linfo[0]), (long)(jited_ksyms[0]))) { >>>> + "jited_linfo[0]:%llx != jited_ksyms[0]:%llx", >>>> + jited_linfo[0], jited_ksyms[0])) { >>>> err = -1; >>>> goto done; >>>> } >>>> @@ -6519,16 +6519,16 @@ static int test_get_linfo(const struct prog_info_raw_test *test, >>>> } >>>> >>>> if (CHECK(jited_linfo[i] <= jited_linfo[i - 1], >>>> - "jited_linfo[%u]:%lx <= jited_linfo[%u]:%lx", >>>> - i, (long)jited_linfo[i], >>>> - i - 1, (long)(jited_linfo[i - 1]))) { >>>> + "jited_linfo[%u]:%llx <= jited_linfo[%u]:%llx", >>>> + i, jited_linfo[i], >>>> + i - 1, (jited_linfo[i - 1]))) { >>>> err = -1; >>>> goto done; >>>> } >>>> >>>> if (CHECK(jited_linfo[i] - cur_func_ksyms > cur_func_len, >>>> - "jited_linfo[%u]:%lx - %lx > %u", >>>> - i, (long)jited_linfo[i], (long)cur_func_ksyms, >>>> + "jited_linfo[%u]:%llx - %llx > %u", >>>> + i, jited_linfo[i], cur_func_ksyms, >>>> cur_func_len)) { >>>> err = -1; >>>> goto done; >>>> -- >>>> 2.25.1 >>>> >>> . >>> > . > ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH -next 2/2] riscv, bpf: Support riscv jit to provide bpf_line_info 2022-04-26 14:09 [PATCH -next 0/2] Support riscv jit to provide bpf_line_info Pu Lehui 2022-04-26 14:09 ` [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo Pu Lehui @ 2022-04-26 14:09 ` Pu Lehui 1 sibling, 0 replies; 7+ messages in thread From: Pu Lehui @ 2022-04-26 14:09 UTC (permalink / raw) To: bpf, linux-riscv, netdev, linux-kernel Cc: bjorn, luke.r.nels, xi.wang, ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend, kpsingh, paul.walmsley, palmer, aou, pulehui Add support for riscv jit to provide bpf_line_info. We need to consider the prologue offset in ctx->offset, but unlike x86 and arm64, ctx->offset of riscv does not provide an extra slot for the prologue, so here we just calculate the len of prologue and add it to ctx->offset at the end. Both RV64 and RV32 have been tested. Signed-off-by: Pu Lehui <pulehui@huawei.com> --- arch/riscv/net/bpf_jit.h | 1 + arch/riscv/net/bpf_jit_core.c | 7 ++++++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h index 2a3715bf29fe..7dbbad7595f0 100644 --- a/arch/riscv/net/bpf_jit.h +++ b/arch/riscv/net/bpf_jit.h @@ -69,6 +69,7 @@ struct rv_jit_context { struct bpf_prog *prog; u16 *insns; /* RV insns */ int ninsns; + int prologue_offset; int epilogue_offset; int *offset; /* BPF to RV */ int nexentries; diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c index be743d700aa7..6383eb591b0d 100644 --- a/arch/riscv/net/bpf_jit_core.c +++ b/arch/riscv/net/bpf_jit_core.c @@ -44,7 +44,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) unsigned int prog_size = 0, extable_size = 0; bool tmp_blinded = false, extra_pass = false; struct bpf_prog *tmp, *orig_prog = prog; - int pass = 0, prev_ninsns = 0, i; + int pass = 0, prev_ninsns = 0, prologue_len, i; struct rv_jit_data *jit_data; struct rv_jit_context *ctx; @@ -95,6 +95,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) prog = orig_prog; goto out_offset; } + ctx->prologue_offset = ctx->ninsns; bpf_jit_build_prologue(ctx); ctx->epilogue_offset = ctx->ninsns; bpf_jit_build_epilogue(ctx); @@ -161,6 +162,10 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) if (!prog->is_func || extra_pass) { bpf_jit_binary_lock_ro(jit_data->header); + prologue_len = ctx->epilogue_offset - ctx->prologue_offset; + for (i = 0; i < prog->len; i++) + ctx->offset[i] = ninsns_rvoff(prologue_len + ctx->offset[i]); + bpf_prog_fill_jited_linfo(prog, ctx->offset); out_offset: kfree(ctx->offset); kfree(jit_data); -- 2.25.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-05-07 0:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-26 14:09 [PATCH -next 0/2] Support riscv jit to provide bpf_line_info Pu Lehui 2022-04-26 14:09 ` [PATCH -next 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo Pu Lehui 2022-04-27 22:33 ` Andrii Nakryiko 2022-04-28 9:47 ` Pu Lehui 2022-05-06 21:01 ` Andrii Nakryiko 2022-05-07 0:48 ` Pu Lehui 2022-04-26 14:09 ` [PATCH -next 2/2] riscv, bpf: Support riscv jit to provide bpf_line_info Pu Lehui
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).