All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.