Message ID | 20230616171728.530116-1-alan.maguire@oracle.com (mailing list archive) |
---|---|
Headers | show |
Series | bpf: support BTF kind layout info, CRCs | expand |
On Fri, Jun 16, 2023 at 06:17:18PM +0100, Alan Maguire wrote: > By separating parsing BTF from using all the information > it provides, we allow BTF to encode new features even if > they cannot be used. This is helpful in particular for > cases where newer tools for BTF generation run on an > older kernel; BTF kinds may be present that the kernel > cannot yet use, but at least it can parse the BTF > provided. Meanwhile userspace tools with newer libbpf > may be able to use the newer information. Overall looks great, but why such narrow formatting? It's much less than 80. > > The intent is to support encoding of kind layouts > optionally so that tools like pahole can add this > information. So for each kind we record > > - kind-related flags > - length of singular element following struct btf_type > - length of each of the btf_vlen() elements following > > In addition we make space in the BTF header for > CRC32s computed over the BTF along with a CRC for > the base BTF; this allows split BTF to identify > a mismatch explicitly. > > The ideas here were discussed at [1], with further > discussion at [2]. > > Future work can take more advantage of these features > such as > > - using base CRC to identify base/module BTF mismatch > explicitly > - using absence of a base BTF CRC as evidence that > BTF is standalone That's fine to have as a follow up, but with BTF_FLAG_CRC_SET the kernel should check the crc. Calling crc32c on modern cpus should be plenty fast. It won't slow down btf verification.
On 17/06/2023 01:39, Alexei Starovoitov wrote: > On Fri, Jun 16, 2023 at 06:17:18PM +0100, Alan Maguire wrote: >> By separating parsing BTF from using all the information >> it provides, we allow BTF to encode new features even if >> they cannot be used. This is helpful in particular for >> cases where newer tools for BTF generation run on an >> older kernel; BTF kinds may be present that the kernel >> cannot yet use, but at least it can parse the BTF >> provided. Meanwhile userspace tools with newer libbpf >> may be able to use the newer information. > > Overall looks great, but > why such narrow formatting? It's much less than 80. > >> >> The intent is to support encoding of kind layouts >> optionally so that tools like pahole can add this >> information. So for each kind we record >> >> - kind-related flags >> - length of singular element following struct btf_type >> - length of each of the btf_vlen() elements following >> >> In addition we make space in the BTF header for >> CRC32s computed over the BTF along with a CRC for >> the base BTF; this allows split BTF to identify >> a mismatch explicitly. >> >> The ideas here were discussed at [1], with further >> discussion at [2]. >> >> Future work can take more advantage of these features >> such as >> >> - using base CRC to identify base/module BTF mismatch >> explicitly >> - using absence of a base BTF CRC as evidence that >> BTF is standalone > > That's fine to have as a follow up, but with BTF_FLAG_CRC_SET > the kernel should check the crc. > Calling crc32c on modern cpus should be plenty fast. > It won't slow down btf verification. Sure; I'll roll this into v3 and fix formatting and the typo in btf.h. Thanks!