On Thu, Oct 18, 2018 at 08:41:52PM +0100, Edward Cree wrote: > On 18/10/18 19:12, Martin Lau wrote: > > The BTF verification and bpf_prog_load() has to treat > > them differently. > > > > Are you suggesting they can be treated the same for > > the kernel verification purpose? > > > > or > > > > The concern is, having two kind, BTF_KIND_FUNC_PROTO and > > BTF_KIND_FUNC, is confusing because they have almost the > > same BTF metadata? > > > > From the BTF perspective, they are different because > > they are allowed to contain different information. > > For example, only "foo" can have func_info in patch 5 > > (the to-be-added line_info can only belong to "foo" also). > Perhaps I'm not properly understanding how BTF is to be used. > But from my perspective, 'foo' is not a type; it's an instance > of a type; i.e. it's a value of type int ()(int). Then by a > kind of metonymy, we are including a BTF record that defines > the type 'foo' as int()(int), in order to state that this is > the type _of_ foo. Similarly, we are including a BTF record > defining 'bar' as the type int (*)(int), thus stating that > the type _of_ bar is int (*)(int). > So everything that's special about 'foo' relates to the fact > that it is a named, rather than anonymous, type, which is > being used to indicate that there is an actual object 'foo' > of this type. > And this is *identical* to how the BTF record "name 'a', type > int" declares an object a, the BTF record "name 'b', type > int *" declares an object b, and the anonymous int type > referenced by b's btf_type.type does not declare an object. > > So either types and objects are represented the same way in > BTF, or not; it's inconsistent to make a distinction between > them for functions but not for other types. > > I know C thinks functions are special, but that's a wart in C > that maybe makes sense in its context but not elsewhere. As I have mentioned earlier, it is also special to the kernel because the BTF verifier and bpf_prog_load() need to do different checks for FUNC and FUNC_PROTO to ensure they are sane.
First, we need to agree that the kernel needs to verify them differently. and then we can proceed to discuss how to distinguish them. We picked the current way to avoid adding a new BTF function section and keep it strict forward to distinguish them w/o relying on other hints from 'struct btf_type'. Are you suggesting another way of doing it?
