On Wed, Feb 10, 2021 at 02:54:40PM -0800, Andrii Nakryiko wrote: > On Wed, Feb 10, 2021 at 1:17 PM Martin KaFai Lau <kafai@xxxxxx> wrote: > > > > On Wed, Feb 10, 2021 at 12:27:38PM -0800, Andrii Nakryiko wrote: > > > On Tue, Feb 9, 2021 at 12:11 PM Martin KaFai Lau <kafai@xxxxxx> wrote: > > > > > > > > This patch adds a "void *owner" member. The existing > > > > bpf_tcp_ca test will ensure the bpf_cubic.o and bpf_dctcp.o > > > > can be loaded. > > > > > > > > Signed-off-by: Martin KaFai Lau <kafai@xxxxxx> > > > > --- > > > > > > Acked-by: Andrii Nakryiko <andrii@xxxxxxxxxx> > > > > > > What will happen if BPF code initializes such non-func ptr member? > > > Will libbpf complain or just ignore those values? Ignoring initialized > > > members isn't great. > > The latter. libbpf will ignore non-func ptr member. The non-func ptr > > member stays zero when it is passed to the kernel. > > > > libbpf can be changed to copy this non-func ptr value. > > The kernel will decide what to do with it. It will > > then be consistent with int/array member like ".name" > > and ".flags" where the kernel will verify the value. > > I can spin v2 to do that. > > I was thinking about erroring out on non-zero fields, but if you think > it's useful to pass through values, it could be done, but will require > more and careful code, probably. So, basically, don't feel obligated > to do this in this patch set. You meant it needs different handling in copying ptr value than copying int/char[]?
