From: Pu Lehui <pulehui@huawei.com> To: John Fastabend <john.fastabend@gmail.com>, <bpf@vger.kernel.org>, <linux-riscv@lists.infradead.org>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> Cc: "Alexei Starovoitov" <ast@kernel.org>, "Daniel Borkmann" <daniel@iogearbox.net>, "Andrii Nakryiko" <andrii@kernel.org>, "Björn Töpel" <bjorn@kernel.org>, "Luke Nelson" <luke.r.nels@gmail.com>, "Xi Wang" <xi.wang@gmail.com>, "Martin KaFai Lau" <kafai@fb.com>, "Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>, "KP Singh" <kpsingh@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Palmer Dabbelt" <palmer@dabbelt.com>, "Albert Ou" <aou@eecs.berkeley.edu> Subject: Re: [PATCH bpf-next v2 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo Date: Sat, 7 May 2022 08:51:00 +0800 [thread overview] Message-ID: <7e1ef7a3-582b-7443-8018-69126efdc587@huawei.com> (raw) In-Reply-To: <62758a83b512a_18fd5208b5@john.notmuch> On 2022/5/7 4:52, John Fastabend wrote: > Pu Lehui 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 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c >> index e9e3e49c0eb7..18137ea5190d 100644 >> --- a/kernel/bpf/syscall.c >> +++ b/kernel/bpf/syscall.c >> @@ -3871,13 +3871,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])) > > the logic is fine but i'm going to nitpick a bit this 4 lines is ugly > just make it slightly longer than 80chars or use a shoarter name? For > example, > > for (i = 0; i < ulen; i++) { > unsigned long l; > > l = (unsigned long) prog->aux->jited_linfo[i]; > if (put_user((__u64) l, &user_linfo[i])) > > is much nicer -- no reason to smash single assignment across multiple > lines. My $.02. > Okay, It sounds good. I will make change in next version. Thanks. > Thanks, > John > . >
WARNING: multiple messages have this Message-ID (diff)
From: Pu Lehui <pulehui@huawei.com> To: John Fastabend <john.fastabend@gmail.com>, <bpf@vger.kernel.org>, <linux-riscv@lists.infradead.org>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> Cc: "Alexei Starovoitov" <ast@kernel.org>, "Daniel Borkmann" <daniel@iogearbox.net>, "Andrii Nakryiko" <andrii@kernel.org>, "Björn Töpel" <bjorn@kernel.org>, "Luke Nelson" <luke.r.nels@gmail.com>, "Xi Wang" <xi.wang@gmail.com>, "Martin KaFai Lau" <kafai@fb.com>, "Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>, "KP Singh" <kpsingh@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Palmer Dabbelt" <palmer@dabbelt.com>, "Albert Ou" <aou@eecs.berkeley.edu> Subject: Re: [PATCH bpf-next v2 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo Date: Sat, 7 May 2022 08:51:00 +0800 [thread overview] Message-ID: <7e1ef7a3-582b-7443-8018-69126efdc587@huawei.com> (raw) In-Reply-To: <62758a83b512a_18fd5208b5@john.notmuch> On 2022/5/7 4:52, John Fastabend wrote: > Pu Lehui 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 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c >> index e9e3e49c0eb7..18137ea5190d 100644 >> --- a/kernel/bpf/syscall.c >> +++ b/kernel/bpf/syscall.c >> @@ -3871,13 +3871,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])) > > the logic is fine but i'm going to nitpick a bit this 4 lines is ugly > just make it slightly longer than 80chars or use a shoarter name? For > example, > > for (i = 0; i < ulen; i++) { > unsigned long l; > > l = (unsigned long) prog->aux->jited_linfo[i]; > if (put_user((__u64) l, &user_linfo[i])) > > is much nicer -- no reason to smash single assignment across multiple > lines. My $.02. > Okay, It sounds good. I will make change in next version. Thanks. > Thanks, > John > . > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-05-07 0:51 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-29 1:42 [PATCH bpf-next v2 0/2] Support riscv jit to provide Pu Lehui 2022-04-29 1:42 ` Pu Lehui 2022-04-29 1:42 ` [PATCH bpf-next v2 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo Pu Lehui 2022-04-29 1:42 ` Pu Lehui 2022-05-06 20:52 ` John Fastabend 2022-05-06 20:52 ` John Fastabend 2022-05-07 0:51 ` Pu Lehui [this message] 2022-05-07 0:51 ` Pu Lehui 2022-04-29 1:42 ` [PATCH bpf-next v2 2/2] riscv, bpf: Support riscv jit to provide bpf_line_info Pu Lehui 2022-04-29 1:42 ` Pu Lehui 2022-05-06 20:59 ` John Fastabend 2022-05-06 20:59 ` John Fastabend 2022-05-06 21:44 ` Luke Nelson 2022-05-06 21:44 ` Luke Nelson 2022-05-26 13:15 ` Pu Lehui 2022-05-26 13:15 ` Pu Lehui
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=7e1ef7a3-582b-7443-8018-69126efdc587@huawei.com \ --to=pulehui@huawei.com \ --cc=andrii@kernel.org \ --cc=aou@eecs.berkeley.edu \ --cc=ast@kernel.org \ --cc=bjorn@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=john.fastabend@gmail.com \ --cc=kafai@fb.com \ --cc=kpsingh@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=luke.r.nels@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=songliubraving@fb.com \ --cc=xi.wang@gmail.com \ --cc=yhs@fb.com \ /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: linkBe 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.