[PATCH bpf-next v3 0/6] Support riscv jit to provide

[PATCH bpf-next v3 0/6] Support riscv jit to provide

[Pu Lehui]

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.
"test_progs -a btf" and "test_bpf.ko" all test pass, as well
as "test_verifier" and "test_progs" with no new failure ceses.

patch 3-6 make some trival cleanup.

v3:
- split kernel changes, libbpf changes, and selftests/bpf changes
into separate patches. (Andrii)
- shorten the name of jited_linfo_addr to avoid line break. (John)
- rename prologue_offset to body_len to make it more sense. (Luke)

v2: https://lore.kernel.org/bpf/20220429014240.3434866-1-pulehui@huawei.com
- Remove some trivial code

v1: https://lore.kernel.org/bpf/20220426140924.3308472-1-pulehui@huawei.com

Pu Lehui (6):
  bpf: Unify data extension operation of jited_ksyms and jited_linfo
  riscv, bpf: Support riscv jit to provide bpf_line_info
  bpf: Correct the comment about insn_to_jit_off
  libbpf: Unify memory address casting operation style
  selftests/bpf: Unify memory address casting operation style
  selftests/bpf: Remove the casting about jited_ksyms and jited_linfo

 arch/riscv/net/bpf_jit.h                     |  1 +
 arch/riscv/net/bpf_jit_core.c                |  8 +++++++-
 kernel/bpf/core.c                            |  2 +-
 kernel/bpf/syscall.c                         |  5 +++--
 tools/lib/bpf/bpf_prog_linfo.c               |  9 +++++----
 tools/testing/selftests/bpf/prog_tests/btf.c | 18 +++++++++---------
 6 files changed, 26 insertions(+), 17 deletions(-)

-- 
2.25.1

[PATCH bpf-next v3 0/6] Support riscv jit to provide

[Pu Lehui]

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.
"test_progs -a btf" and "test_bpf.ko" all test pass, as well
as "test_verifier" and "test_progs" with no new failure ceses.

patch 3-6 make some trival cleanup.

v3:
- split kernel changes, libbpf changes, and selftests/bpf changes
into separate patches. (Andrii)
- shorten the name of jited_linfo_addr to avoid line break. (John)
- rename prologue_offset to body_len to make it more sense. (Luke)

v2: https://lore.kernel.org/bpf/20220429014240.3434866-1-pulehui@huawei.com
- Remove some trivial code

v1: https://lore.kernel.org/bpf/20220426140924.3308472-1-pulehui@huawei.com

Pu Lehui (6):
  bpf: Unify data extension operation of jited_ksyms and jited_linfo
  riscv, bpf: Support riscv jit to provide bpf_line_info
  bpf: Correct the comment about insn_to_jit_off
  libbpf: Unify memory address casting operation style
  selftests/bpf: Unify memory address casting operation style
  selftests/bpf: Remove the casting about jited_ksyms and jited_linfo

 arch/riscv/net/bpf_jit.h                     |  1 +
 arch/riscv/net/bpf_jit_core.c                |  8 +++++++-
 kernel/bpf/core.c                            |  2 +-
 kernel/bpf/syscall.c                         |  5 +++--
 tools/lib/bpf/bpf_prog_linfo.c               |  9 +++++----
 tools/testing/selftests/bpf/prog_tests/btf.c | 18 +++++++++---------
 6 files changed, 26 insertions(+), 17 deletions(-)

-- 
2.25.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH bpf-next v3 1/6] bpf: Unify data extension operation of jited_ksyms and jited_linfo

[Pu Lehui]

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, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index e0aead17dff4..2929a4aab82c 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -4095,14 +4095,15 @@ 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 ladd;
 			__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],
-					     &user_linfo[i]))
+				ladd = (unsigned long)prog->aux->jited_linfo[i];
+				if (put_user((__u64)ladd, &user_linfo[i]))
 					return -EFAULT;
 			}
 		} else {
-- 
2.25.1

[PATCH bpf-next v3 1/6] bpf: Unify data extension operation of jited_ksyms and jited_linfo

[Pu Lehui]

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, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index e0aead17dff4..2929a4aab82c 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -4095,14 +4095,15 @@ 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 ladd;
 			__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],
-					     &user_linfo[i]))
+				ladd = (unsigned long)prog->aux->jited_linfo[i];
+				if (put_user((__u64)ladd, &user_linfo[i]))
 					return -EFAULT;
 			}
 		} else {
-- 
2.25.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH bpf-next v3 2/6] riscv, bpf: Support riscv jit to provide bpf_line_info

[Pu Lehui]

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 | 8 +++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index 2a3715bf29fe..d926e0f7ef57 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 body_len;
 	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..737baf8715da 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->body_len = ctx->ninsns;
 		bpf_jit_build_prologue(ctx);
 		ctx->epilogue_offset = ctx->ninsns;
 		bpf_jit_build_epilogue(ctx);
@@ -161,6 +162,11 @@ 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->body_len;
+		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

[PATCH bpf-next v3 2/6] riscv, bpf: Support riscv jit to provide bpf_line_info

[Pu Lehui]

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 | 8 +++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index 2a3715bf29fe..d926e0f7ef57 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 body_len;
 	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..737baf8715da 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->body_len = ctx->ninsns;
 		bpf_jit_build_prologue(ctx);
 		ctx->epilogue_offset = ctx->ninsns;
 		bpf_jit_build_epilogue(ctx);
@@ -161,6 +162,11 @@ 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->body_len;
+		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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH bpf-next v3 3/6] bpf: Correct the comment about insn_to_jit_off

[Pu Lehui]

The insn_to_jit_off passed to bpf_prog_fill_jited_linfo should be
the first byte of the next instruction, or the byte off to the end
of the current instruction.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
 kernel/bpf/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 13e9dbeeedf3..197fad955c46 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -176,7 +176,7 @@ void bpf_prog_jit_attempt_done(struct bpf_prog *prog)
  * here is relative to the prog itself instead of the main prog.
  * This array has one entry for each xlated bpf insn.
  *
- * jited_off is the byte off to the last byte of the jited insn.
+ * jited_off is the byte off to the end of the jited insn.
  *
  * Hence, with
  * insn_start:
-- 
2.25.1

[PATCH bpf-next v3 3/6] bpf: Correct the comment about insn_to_jit_off

[Pu Lehui]

The insn_to_jit_off passed to bpf_prog_fill_jited_linfo should be
the first byte of the next instruction, or the byte off to the end
of the current instruction.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
 kernel/bpf/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 13e9dbeeedf3..197fad955c46 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -176,7 +176,7 @@ void bpf_prog_jit_attempt_done(struct bpf_prog *prog)
  * here is relative to the prog itself instead of the main prog.
  * This array has one entry for each xlated bpf insn.
  *
- * jited_off is the byte off to the last byte of the jited insn.
+ * jited_off is the byte off to the end of the jited insn.
  *
  * Hence, with
  * insn_start:
-- 
2.25.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Pu Lehui]

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);
 
 	nr_jited_func = info->nr_jited_ksyms;
 	if (!nr_jited_func ||
@@ -148,7 +149,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 +167,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;
-- 
2.25.1

[PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Pu Lehui]

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);
 
 	nr_jited_func = info->nr_jited_ksyms;
 	if (!nr_jited_func ||
@@ -148,7 +149,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 +167,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;
-- 
2.25.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH bpf-next v3 5/6] selftests/bpf: Unify memory address casting operation style

[Pu Lehui]

The members of bpf_prog_info, which are line_info and jited_line_info
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/testing/selftests/bpf/prog_tests/btf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
index ba5bde53d418..e6612f2bd0cf 100644
--- a/tools/testing/selftests/bpf/prog_tests/btf.c
+++ b/tools/testing/selftests/bpf/prog_tests/btf.c
@@ -6550,8 +6550,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;
 	}
-- 
2.25.1

[PATCH bpf-next v3 5/6] selftests/bpf: Unify memory address casting operation style

[Pu Lehui]

The members of bpf_prog_info, which are line_info and jited_line_info
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/testing/selftests/bpf/prog_tests/btf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
index ba5bde53d418..e6612f2bd0cf 100644
--- a/tools/testing/selftests/bpf/prog_tests/btf.c
+++ b/tools/testing/selftests/bpf/prog_tests/btf.c
@@ -6550,8 +6550,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;
 	}
-- 
2.25.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH bpf-next v3 6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo

[Pu Lehui]

We have unified data extension operation of jited_ksyms and jited_linfo
into zero extension, so there's no need to cast u64 memory address to
long data type.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
 tools/testing/selftests/bpf/prog_tests/btf.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
index e6612f2bd0cf..65bdc4aa0a63 100644
--- a/tools/testing/selftests/bpf/prog_tests/btf.c
+++ b/tools/testing/selftests/bpf/prog_tests/btf.c
@@ -6599,8 +6599,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;
 	}
@@ -6618,16 +6618,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

[PATCH bpf-next v3 6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo

[Pu Lehui]

We have unified data extension operation of jited_ksyms and jited_linfo
into zero extension, so there's no need to cast u64 memory address to
long data type.

Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
 tools/testing/selftests/bpf/prog_tests/btf.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
index e6612f2bd0cf..65bdc4aa0a63 100644
--- a/tools/testing/selftests/bpf/prog_tests/btf.c
+++ b/tools/testing/selftests/bpf/prog_tests/btf.c
@@ -6599,8 +6599,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;
 	}
@@ -6618,16 +6618,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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH bpf-next v3 0/6] Support riscv jit to provide

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:

On Mon, 30 May 2022 17:28:09 +0800 you wrote:
> 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.
> "test_progs -a btf" and "test_bpf.ko" all test pass, as well
> as "test_verifier" and "test_progs" with no new failure ceses.
> 
> [...]

Here is the summary with links:
  - [bpf-next,v3,1/6] bpf: Unify data extension operation of jited_ksyms and jited_linfo
    (no matching commit)
  - [bpf-next,v3,2/6] riscv, bpf: Support riscv jit to provide bpf_line_info
    https://git.kernel.org/bpf/bpf-next/c/b863b163aa8a
  - [bpf-next,v3,3/6] bpf: Correct the comment about insn_to_jit_off
    https://git.kernel.org/bpf/bpf-next/c/4b4b4f94a4f6
  - [bpf-next,v3,4/6] libbpf: Unify memory address casting operation style
    (no matching commit)
  - [bpf-next,v3,5/6] selftests/bpf: Unify memory address casting operation style
    (no matching commit)
  - [bpf-next,v3,6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH bpf-next v3 0/6] Support riscv jit to provide

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:

On Mon, 30 May 2022 17:28:09 +0800 you wrote:
> 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.
> "test_progs -a btf" and "test_bpf.ko" all test pass, as well
> as "test_verifier" and "test_progs" with no new failure ceses.
> 
> [...]

Here is the summary with links:
  - [bpf-next,v3,1/6] bpf: Unify data extension operation of jited_ksyms and jited_linfo
    (no matching commit)
  - [bpf-next,v3,2/6] riscv, bpf: Support riscv jit to provide bpf_line_info
    https://git.kernel.org/bpf/bpf-next/c/b863b163aa8a
  - [bpf-next,v3,3/6] bpf: Correct the comment about insn_to_jit_off
    https://git.kernel.org/bpf/bpf-next/c/4b4b4f94a4f6
  - [bpf-next,v3,4/6] libbpf: Unify memory address casting operation style
    (no matching commit)
  - [bpf-next,v3,5/6] selftests/bpf: Unify memory address casting operation style
    (no matching commit)
  - [bpf-next,v3,6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Daniel Borkmann]

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.

Thanks,
Daniel

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Daniel Borkmann]

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.

Thanks,
Daniel

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Andrii Nakryiko]

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

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Andrii Nakryiko]

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

Re: [PATCH bpf-next v3 6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo

[Andrii Nakryiko]

On Mon, May 30, 2022 at 1:58 AM Pu Lehui <pulehui@huawei.com> wrote:
>
> We have unified data extension operation of jited_ksyms and jited_linfo
> into zero extension, so there's no need to cast u64 memory address to
> long data type.
>
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
> ---
>  tools/testing/selftests/bpf/prog_tests/btf.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
> index e6612f2bd0cf..65bdc4aa0a63 100644
> --- a/tools/testing/selftests/bpf/prog_tests/btf.c
> +++ b/tools/testing/selftests/bpf/prog_tests/btf.c
> @@ -6599,8 +6599,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])) {

__u64 is not always printed with %lld, on some platforms it is
actually %ld, so to avoid compiler warnings we just cast them to long
long or unsigned long long (and then %lld or %llu is fine). So please
update this part here and below.

>                 err = -1;
>                 goto done;
>         }
> @@ -6618,16 +6618,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
>

Re: [PATCH bpf-next v3 6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo

[Andrii Nakryiko]

On Mon, May 30, 2022 at 1:58 AM Pu Lehui <pulehui@huawei.com> wrote:
>
> We have unified data extension operation of jited_ksyms and jited_linfo
> into zero extension, so there's no need to cast u64 memory address to
> long data type.
>
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
> ---
>  tools/testing/selftests/bpf/prog_tests/btf.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
> index e6612f2bd0cf..65bdc4aa0a63 100644
> --- a/tools/testing/selftests/bpf/prog_tests/btf.c
> +++ b/tools/testing/selftests/bpf/prog_tests/btf.c
> @@ -6599,8 +6599,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])) {

__u64 is not always printed with %lld, on some platforms it is
actually %ld, so to avoid compiler warnings we just cast them to long
long or unsigned long long (and then %lld or %llu is fine). So please
update this part here and below.

>                 err = -1;
>                 goto done;
>         }
> @@ -6618,16 +6618,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
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Pu Lehui]

On 2022/5/31 5:03, Daniel Borkmann 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.
> 

sorry for reply so late, I will take this soon.

> Thanks,
> Daniel
> .

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Pu Lehui]

On 2022/5/31 5:03, Daniel Borkmann 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.
> 

sorry for reply so late, I will take this soon.

> Thanks,
> Daniel
> .

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH bpf-next v3 6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo

[Pu Lehui]

On 2022/6/4 5:05, Andrii Nakryiko wrote:
> On Mon, May 30, 2022 at 1:58 AM Pu Lehui <pulehui@huawei.com> wrote:
>>
>> We have unified data extension operation of jited_ksyms and jited_linfo
>> into zero extension, so there's no need to cast u64 memory address to
>> long data type.
>>
>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>> ---
>>   tools/testing/selftests/bpf/prog_tests/btf.c | 14 +++++++-------
>>   1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
>> index e6612f2bd0cf..65bdc4aa0a63 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/btf.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/btf.c
>> @@ -6599,8 +6599,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])) {
> 
> __u64 is not always printed with %lld, on some platforms it is
> actually %ld, so to avoid compiler warnings we just cast them to long
> long or unsigned long long (and then %lld or %llu is fine). So please
> update this part here and below.
> 

I found that __u64 in ppc64 actually is defined to be unsigned long. I 
will update it. Thanks.

>>                  err = -1;
>>                  goto done;
>>          }
>> @@ -6618,16 +6618,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
>>
> .
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH bpf-next v3 6/6] selftests/bpf: Remove the casting about jited_ksyms and jited_linfo

[Pu Lehui]

On 2022/6/4 5:05, Andrii Nakryiko wrote:
> On Mon, May 30, 2022 at 1:58 AM Pu Lehui <pulehui@huawei.com> wrote:
>>
>> We have unified data extension operation of jited_ksyms and jited_linfo
>> into zero extension, so there's no need to cast u64 memory address to
>> long data type.
>>
>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>> ---
>>   tools/testing/selftests/bpf/prog_tests/btf.c | 14 +++++++-------
>>   1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/btf.c b/tools/testing/selftests/bpf/prog_tests/btf.c
>> index e6612f2bd0cf..65bdc4aa0a63 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/btf.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/btf.c
>> @@ -6599,8 +6599,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])) {
> 
> __u64 is not always printed with %lld, on some platforms it is
> actually %ld, so to avoid compiler warnings we just cast them to long
> long or unsigned long long (and then %lld or %llu is fine). So please
> update this part here and below.
> 

I found that __u64 in ppc64 actually is defined to be unsigned long. I 
will update it. Thanks.

>>                  err = -1;
>>                  goto done;
>>          }
>> @@ -6618,16 +6618,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
>>
> .
> 

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Pu Lehui]

On 2022/6/4 5:03, Andrii Nakryiko wrote:
> 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) ?
> 

I also think that (void *)(uintptr_t) would be the best replacement. I 
applied the changes to kernel/bpf and samples/bpf, and it worked fine. 
But in selftests/bpf, the following similar error occur at compile time:

progs/test_cls_redirect.c:504:11: error: cast to 'uint8_t *' (aka 
'unsigned char *') from smaller integer type 'uintptr_t' (aka 'unsigned 
int') [-Werror,-Wint-to-pointer-cast]
	.head = (uint8_t *)(uintptr_t)skb->data,

I take clang to compile with the front and back end separation, like 
samples/bpf, and it works. It seems that the all-in-one clang has 
problems handling the uintptr_t.

>>
>> Thanks,
>> Daniel
> .
> 

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Pu Lehui]

On 2022/6/4 5:03, Andrii Nakryiko wrote:
> 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) ?
> 

I also think that (void *)(uintptr_t) would be the best replacement. I 
applied the changes to kernel/bpf and samples/bpf, and it worked fine. 
But in selftests/bpf, the following similar error occur at compile time:

progs/test_cls_redirect.c:504:11: error: cast to 'uint8_t *' (aka 
'unsigned char *') from smaller integer type 'uintptr_t' (aka 'unsigned 
int') [-Werror,-Wint-to-pointer-cast]
	.head = (uint8_t *)(uintptr_t)skb->data,

I take clang to compile with the front and back end separation, like 
samples/bpf, and it works. It seems that the all-in-one clang has 
problems handling the uintptr_t.

>>
>> Thanks,
>> Daniel
> .
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Andrii Nakryiko]

On Thu, Jul 7, 2022 at 5:23 AM Pu Lehui <pulehui@huawei.com> wrote:
>
>
>
> On 2022/6/4 5:03, Andrii Nakryiko wrote:
> > 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) ?
> >
>
> I also think that (void *)(uintptr_t) would be the best replacement. I
> applied the changes to kernel/bpf and samples/bpf, and it worked fine.
> But in selftests/bpf, the following similar error occur at compile time:
>
> progs/test_cls_redirect.c:504:11: error: cast to 'uint8_t *' (aka
> 'unsigned char *') from smaller integer type 'uintptr_t' (aka 'unsigned
> int') [-Werror,-Wint-to-pointer-cast]
>         .head = (uint8_t *)(uintptr_t)skb->data,

this is BPF-side code so using system's uintptr_t definition won't
work correctly here. Just do (unsigned long) instead?

>
> I take clang to compile with the front and back end separation, like
> samples/bpf, and it works. It seems that the all-in-one clang has
> problems handling the uintptr_t.
>
> >>
> >> Thanks,
> >> Daniel
> > .
> >

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Andrii Nakryiko]

On Thu, Jul 7, 2022 at 5:23 AM Pu Lehui <pulehui@huawei.com> wrote:
>
>
>
> On 2022/6/4 5:03, Andrii Nakryiko wrote:
> > 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) ?
> >
>
> I also think that (void *)(uintptr_t) would be the best replacement. I
> applied the changes to kernel/bpf and samples/bpf, and it worked fine.
> But in selftests/bpf, the following similar error occur at compile time:
>
> progs/test_cls_redirect.c:504:11: error: cast to 'uint8_t *' (aka
> 'unsigned char *') from smaller integer type 'uintptr_t' (aka 'unsigned
> int') [-Werror,-Wint-to-pointer-cast]
>         .head = (uint8_t *)(uintptr_t)skb->data,

this is BPF-side code so using system's uintptr_t definition won't
work correctly here. Just do (unsigned long) instead?

>
> I take clang to compile with the front and back end separation, like
> samples/bpf, and it works. It seems that the all-in-one clang has
> problems handling the uintptr_t.
>
> >>
> >> Thanks,
> >> Daniel
> > .
> >

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Pu Lehui]

On 2022/7/9 6:30, Andrii Nakryiko wrote:
> On Thu, Jul 7, 2022 at 5:23 AM Pu Lehui <pulehui@huawei.com> wrote:
>>
>>
>>
>> On 2022/6/4 5:03, Andrii Nakryiko wrote:
>>> 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) ?
>>>
>>
>> I also think that (void *)(uintptr_t) would be the best replacement. I
>> applied the changes to kernel/bpf and samples/bpf, and it worked fine.
>> But in selftests/bpf, the following similar error occur at compile time:
>>
>> progs/test_cls_redirect.c:504:11: error: cast to 'uint8_t *' (aka
>> 'unsigned char *') from smaller integer type 'uintptr_t' (aka 'unsigned
>> int') [-Werror,-Wint-to-pointer-cast]
>>          .head = (uint8_t *)(uintptr_t)skb->data,
> 
> this is BPF-side code so using system's uintptr_t definition won't
> work correctly here. Just do (unsigned long) instead?
> 

It is fine by me, and for this cleanup

>>
>> I take clang to compile with the front and back end separation, like
>> samples/bpf, and it works. It seems that the all-in-one clang has
>> problems handling the uintptr_t.
>>
>>>>
>>>> Thanks,
>>>> Daniel
>>> .
>>>
> .
> 

Re: [PATCH bpf-next v3 4/6] libbpf: Unify memory address casting operation style

[Pu Lehui]

On 2022/7/9 6:30, Andrii Nakryiko wrote:
> On Thu, Jul 7, 2022 at 5:23 AM Pu Lehui <pulehui@huawei.com> wrote:
>>
>>
>>
>> On 2022/6/4 5:03, Andrii Nakryiko wrote:
>>> 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) ?
>>>
>>
>> I also think that (void *)(uintptr_t) would be the best replacement. I
>> applied the changes to kernel/bpf and samples/bpf, and it worked fine.
>> But in selftests/bpf, the following similar error occur at compile time:
>>
>> progs/test_cls_redirect.c:504:11: error: cast to 'uint8_t *' (aka
>> 'unsigned char *') from smaller integer type 'uintptr_t' (aka 'unsigned
>> int') [-Werror,-Wint-to-pointer-cast]
>>          .head = (uint8_t *)(uintptr_t)skb->data,
> 
> this is BPF-side code so using system's uintptr_t definition won't
> work correctly here. Just do (unsigned long) instead?
> 

It is fine by me, and for this cleanup

>>
>> I take clang to compile with the front and back end separation, like
>> samples/bpf, and it works. It seems that the all-in-one clang has
>> problems handling the uintptr_t.
>>
>>>>
>>>> Thanks,
>>>> Daniel
>>> .
>>>
> .
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv