struct_ops: value type should allow nested structs and unions

[lmb]

We should not error here, just ignore it.

There are struct ops which have nested structs such as struct tcp_congestion_ops. When working with a definition copied from sources or vmlinux.h, you hit this.

Originally posted by @dylandreimerink in #1845 (comment)

The fix is to make the copy function recursive.

[lmb]

cc @shun159

[lmb]

A great way to test this is re-enabling StructOps in LibBPFCompat.

[shun159]

@lmb ack!

[shun159]

@lmb @dylandreimerink

I feel that the guard below is a bit too strict compared to the implementation in libbpf:
https://github.com/cilium/ebpf/blob/main/collection.go#L765-L768

IMO, it might be better to only check whether the kernel and user types have matching sizes,
and allow the byte copy, but I’d appreciate your thoughts on this approach.

For reference, here’s the related code from libbpf:
https://github.com/libbpf/libbpf/blob/master/src/libbpf.c#L1314

[lmb]

I disagree and think that libbpf doesn't have good behaviour. Essentially it special cases the outermost struct, but ignores the fact that structs are recursive types. It doesn't return an error for example when the nested struct has function pointers which might need to be initialised by the library (not saying that works now, but it's a bit sloppy).

We should check that size matches, and that the user value is all zero. In that case we skip the copy. Otherwise we return an error indicating that nested, non-zero structs are not supported.

[shun159]

@lmb got it. I will proceed with raising a new PR as the above.

[shun159]

@lmb could you please review the PR at your leisure?