Re: [PATCH bpf-next v2] bpf: net: emit anonymous enum with BPF_TCP_CLOSE value explicitly

[Yonghong Song <yhs@fb.com>]

On 3/16/21 10:44 PM, Alexei Starovoitov wrote:
> On Tue, Mar 16, 2021 at 9:29 PM Yonghong Song <yhs@fb.com> wrote:
>> +       BTF_TYPE_EMIT_ENUM(BPF_TCP_ESTABLISHED);
>> +
>> +       return 0;
>> +}
>> +late_initcall(bpf_emit_btf_type);
> 
> I think if we burn a dummy function on this it would be a wrong
> pattern to follow.

Maybe we can pick another initcall to piggyback?

> This is just a nop C statement.
> Typically we add BUILD_BUG_ON near the places that rely on that constraint.
> There is such a function already. It's tcp_set_state() as you pointed out.
> It's not using BTF of course, but I would move above BTF_TYPE_EMIT_ENUM there.
> I'm not sure why you're calling it "pollute net/ipv4/tcp.c".

This is the minor reason. I first coded in that place and feel awkward
where we have macro referenced above and we still emit a BTF_TYPE_EMIT
below although with some comments.

The major reason is I think we may have some uapi type/enum's (e.g., in 
uapi/linux/bpf.h) which will be used in bpf program but not in kernel
itself. So we cannot generate types in vmlinux btf because of this. So I
used this case to find a place to generate these btf types.
BPF_TCP_CLOSE is actually such an example, it happens we have a 
BUILD_BUG_ON in kernel to access it.
Maybe I am too forward looking?

> Consider that BTF_TYPE_EMIT macro is serving similar purpose
> and it's scattered around net/core/filter.c