From: Andrii Nakryiko <andrii.nakryiko@gmail.com> To: Daniel Borkmann <daniel@iogearbox.net> Cc: "Pu Lehui" <pulehui@huawei.com>, bpf <bpf@vger.kernel.org>, linux-riscv@lists.infradead.org, Networking <netdev@vger.kernel.org>, "open list" <linux-kernel@vger.kernel.org>, "Alexei Starovoitov" <ast@kernel.org>, "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>, "John Fastabend" <john.fastabend@gmail.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 v3 4/6] libbpf: Unify memory address casting operation style Date: Fri, 3 Jun 2022 14:03:06 -0700 [thread overview] Message-ID: <CAEf4BzacrRNDDYFR_4GH40+wxff=hCiyxymig6N+NVrM537AAA@mail.gmail.com> (raw) In-Reply-To: <a31efed5-a436-49c9-4126-902303df9766@iogearbox.net> On Mon, May 30, 2022 at 2:03 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > On 5/30/22 11:28 AM, Pu Lehui wrote: > > The members of bpf_prog_info, which are line_info, jited_line_info, > > jited_ksyms and jited_func_lens, store u64 address pointed to the > > corresponding memory regions. Memory addresses are conceptually > > unsigned, (unsigned long) casting makes more sense, so let's make > > a change for conceptual uniformity. > > > > Signed-off-by: Pu Lehui <pulehui@huawei.com> > > --- > > tools/lib/bpf/bpf_prog_linfo.c | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/tools/lib/bpf/bpf_prog_linfo.c b/tools/lib/bpf/bpf_prog_linfo.c > > index 5c503096ef43..7beb060d0671 100644 > > --- a/tools/lib/bpf/bpf_prog_linfo.c > > +++ b/tools/lib/bpf/bpf_prog_linfo.c > > @@ -127,7 +127,8 @@ 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); > > Took in patch 1-3, lgtm, thanks! My question around the cleanups in patch 4-6 ... > there are various other such cases e.g. in libbpf, perhaps makes sense to clean all > of them up at once and not just the 4 locations in here. if (void *)(long) pattern is wrong, then I guess the best replacement should be (void *)(uintptr_t) ? > > Thanks, > Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Andrii Nakryiko <andrii.nakryiko@gmail.com> To: Daniel Borkmann <daniel@iogearbox.net> Cc: "Pu Lehui" <pulehui@huawei.com>, bpf <bpf@vger.kernel.org>, linux-riscv@lists.infradead.org, Networking <netdev@vger.kernel.org>, "open list" <linux-kernel@vger.kernel.org>, "Alexei Starovoitov" <ast@kernel.org>, "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>, "John Fastabend" <john.fastabend@gmail.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 v3 4/6] libbpf: Unify memory address casting operation style Date: Fri, 3 Jun 2022 14:03:06 -0700 [thread overview] Message-ID: <CAEf4BzacrRNDDYFR_4GH40+wxff=hCiyxymig6N+NVrM537AAA@mail.gmail.com> (raw) In-Reply-To: <a31efed5-a436-49c9-4126-902303df9766@iogearbox.net> On Mon, May 30, 2022 at 2:03 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > On 5/30/22 11:28 AM, Pu Lehui wrote: > > The members of bpf_prog_info, which are line_info, jited_line_info, > > jited_ksyms and jited_func_lens, store u64 address pointed to the > > corresponding memory regions. Memory addresses are conceptually > > unsigned, (unsigned long) casting makes more sense, so let's make > > a change for conceptual uniformity. > > > > Signed-off-by: Pu Lehui <pulehui@huawei.com> > > --- > > tools/lib/bpf/bpf_prog_linfo.c | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/tools/lib/bpf/bpf_prog_linfo.c b/tools/lib/bpf/bpf_prog_linfo.c > > index 5c503096ef43..7beb060d0671 100644 > > --- a/tools/lib/bpf/bpf_prog_linfo.c > > +++ b/tools/lib/bpf/bpf_prog_linfo.c > > @@ -127,7 +127,8 @@ 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); > > Took in patch 1-3, lgtm, thanks! My question around the cleanups in patch 4-6 ... > there are various other such cases e.g. in libbpf, perhaps makes sense to clean all > of them up at once and not just the 4 locations in here. if (void *)(long) pattern is wrong, then I guess the best replacement should be (void *)(uintptr_t) ? > > Thanks, > Daniel _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-06-03 21:03 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-30 9:28 [PATCH bpf-next v3 0/6] Support riscv jit to provide Pu Lehui 2022-05-30 9:28 ` Pu Lehui 2022-05-30 9:28 ` [PATCH bpf-next v3 1/6] bpf: Unify data extension operation of jited_ksyms and jited_linfo Pu Lehui 2022-05-30 9:28 ` Pu Lehui 2022-05-30 9:28 ` [PATCH bpf-next v3 2/6] riscv, bpf: Support riscv jit to provide bpf_line_info Pu Lehui 2022-05-30 9:28 ` Pu Lehui 2022-05-30 9:28 ` [PATCH bpf-next v3 3/6] bpf: Correct the comment about insn_to_jit_off Pu Lehui 2022-05-30 9:28 ` Pu Lehui 2022-05-30 9:28 ` [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style Pu Lehui 2022-05-30 9:28 ` Pu Lehui 2022-05-30 21:03 ` Daniel Borkmann 2022-05-30 21:03 ` Daniel Borkmann 2022-06-03 21:03 ` Andrii Nakryiko [this message] 2022-06-03 21:03 ` Andrii Nakryiko 2022-07-07 12:23 ` Pu Lehui 2022-07-07 12:23 ` Pu Lehui 2022-07-08 22:30 ` Andrii Nakryiko 2022-07-08 22:30 ` Andrii Nakryiko 2022-07-09 1:32 ` Pu Lehui 2022-07-09 1:32 ` Pu Lehui 2022-07-07 11:49 ` Pu Lehui 2022-07-07 11:49 ` Pu Lehui 2022-05-30 9:28 ` [PATCH bpf-next v3 5/6] selftests/bpf: " Pu Lehui 2022-05-30 9:28 ` Pu Lehui 2022-05-30 9:28 ` [PATCH bpf-next v3 6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo Pu Lehui 2022-05-30 9:28 ` Pu Lehui 2022-06-03 21:05 ` Andrii Nakryiko 2022-06-03 21:05 ` Andrii Nakryiko 2022-07-07 11:55 ` Pu Lehui 2022-07-07 11:55 ` Pu Lehui 2022-05-30 21:00 ` [PATCH bpf-next v3 0/6] Support riscv jit to provide patchwork-bot+netdevbpf 2022-05-30 21:00 ` 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='CAEf4BzacrRNDDYFR_4GH40+wxff=hCiyxymig6N+NVrM537AAA@mail.gmail.com' \ --to=andrii.nakryiko@gmail.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=pulehui@huawei.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.