On Mon, Jun 23, 2025 at 2:45 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Mon, 2025-06-23 at 14:38 -0700, Andrii Nakryiko wrote: > > On Thu, Jun 19, 2025 at 11:17 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > > > > > On Thu, 2025-06-19 at 11:13 -0700, Eduard Zingerman wrote: > > > > > > [...] > > > > > > > Also, what's the plan if you'd like to memset only a fragment of the > > > > memory pointed-to by dynptr? > > > > > > Oh, I see, there is bpf_dynptr_adjust(), sorry for the noise. > > > > > > > Even though we do have bpf_dynptr_adjust() for maximum generality and > > flexibility, for most dynptr-based APIs we try to pass also additional > > offset into dynptr to avoid unnecessary overhead. So it's not a bad > > idea to add this to bpf_memset(), IMO. > > > > bpf_memset(struct bpf_dynptr *dptr, u32 off, u8 val, u32 n) ? > > > > a bit unfortunate that we have 3 integers that you need to be careful > > to not swap accidentally, but even with just val and n you'd have to > > be careful. For other APIs we normally have offset to follow dynptr > > pointer, so hopefully this arrangement won't that surprising. > > > > Thoughts? > > Unfortunate indeed. > The off and n being separated looks weird, tbh. > For dynptr funcs we actually have "dptr, off, size" everywhere, maybe > do the same here? yep, fine by me. I never liked libc's memset() order anyways :)
