Re: [PATCH bpf-next v2 1/7] bpf: Implement bpf_probe_read_kernel_dynptr helper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2025/1/28 06:04, Alexei Starovoitov wrote:
On Sat, Jan 25, 2025 at 5:05 PM Levi Zim <rsworktech@xxxxxxxxxxx> wrote:
On 2025/1/26 00:58, Alexei Starovoitov wrote:
  > On Sat, Jan 25, 2025 at 12:30 AM Levi Zim via B4 Relay
  > <devnull+rsworktech.outlook.com@xxxxxxxxxx> wrote:
  >> From: Levi Zim <rsworktech@xxxxxxxxxxx>
  >>
  >> This patch add a helper function bpf_probe_read_kernel_dynptr:
  >>
  >> long bpf_probe_read_kernel_dynptr(const struct bpf_dynptr *dst,
  >>          u32 offset, u32 size, const void *unsafe_ptr, u64 flags);
  > We stopped adding helpers years ago.
  > Only new kfuncs are allowed.

Sorry, I didn't know that. Just asking, is there any
documentation/discussion
about stopping adding helpers?

I will switch the implementation to kfuncs in v3.

  > This particular one doesn't look useful as-is.
  > The same logic can be expressed with
  > - create dynptr
  > - dynptr_slice
  > - copy_from_kernel

By copy_from_kernel I assume you mean bpf_probe_read_kernel. The problem
with dynptr_slice_rdwr and probe_read_kernel is that they only support a
compile-time constant size [1].

But in order to best utilize the space on a BPF ringbuf, it is possible
to reserve a
variable length of space as dynptr on a ringbuf with
bpf_ringbuf_reserve_dynptr.
That makes sense. The commit log didn't call it out.
Please spell out the motivation clearly.
Thanks for the advice! I will include it in v3.
Also why bpf_probe_read_kernel_common ?
Do we need to memset() it on failure?
Since the current patch is basically a thin wrapper around bpf_probe_read_kernel,
I think we'd better not deviate from the wrapped function.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux