Re: [PATCH v3 bpf-next 11/11] Documentation/bpf: Describe new location-related BTF kinds

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] bpf: BTF_KIND_LOCSEC offset definition is broken for kernel modules
- [Medium] bpf: BTF_KIND_LOC_PARAM size restricts representing larger function parameters
--

commit 2c604400821fbb8c84a44304f76a074c263fd25e
Author: Alan Maguire <alan.maguire@oracle.com>

Documentation/bpf: Describe new location-related BTF kinds

Update BTF specification to describe encoding schemes for
BTF_KIND_LOC_PARAM, BTF_KIND_LOC_PROTO and BTF_KIND_LOCSEC.

> diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
> index 004aa1058d857..70ab6ad608ae5 100644
> --- a/Documentation/bpf/btf.rst
> +++ b/Documentation/bpf/btf.rst

[ ... ]

> @@ -563,6 +568,77 @@ The ``btf_enum64`` encoding:
>  If the original enum value is signed and the size is less than 8,
>  that value will be sign extended into 8 bytes.
>  
> +2.2.20 BTF_KIND_LOC_PARAM
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +``struct btf_type`` encoding requirement:
> +  * ``name_off``: 0
> +  * ``info.kind_flag``: 0
> +  * ``info.kind``: BTF_KIND_LOC_PARAM
> +  * ``info.vlen``: number of 32-bit location value words
> +  * ``size``: size in bytes of the represented parameter: 1, 2, 4, 8 or 16

[Severity: Medium]
Does this limitation restrict representing parameters larger than 16 bytes?

If the UAPI restricts the size to a maximum of 16 bytes, it prevents BPF from
accurately describing functions with large by-value parameters. For example,
structures passed by value on the stack, or ARM64 Homogeneous Floating-point
Aggregates that can be up to 64 bytes.

[ ... ]

> +2.2.22 BTF_KIND_LOCSEC
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +``struct btf_type`` encoding requirement:
> +  * ``name_off``: offset to a valid ELF section name
> +  * ``info.kind_flag``: 0
> +  * ``info.kind``: BTF_KIND_LOCSEC
> +  * ``info.vlen``: number of inline sites in the section
> +  * ``type``: 0
> +
> +``btf_type`` is followed by ``info.vlen`` number of ``struct btf_loc``.::
> +
> +    struct btf_loc {
> +        __u32 func;
> +        __u32 loc_proto;
> +        __u32 offset;
> +    };
> +
> +The ``func`` field is the non-zero type ID of the ``BTF_KIND_FUNC`` being
> +described. ``loc_proto`` is the non-zero type ID of the associated
> +``BTF_KIND_LOC_PROTO``. ``offset`` is the location address offset relative to
> +the kernel or module base address. A LOCSEC named ``inline.text``, for example,
> +contains inline-site records for the ``.text`` section.

[Severity: Medium]
Is this definition of the offset field correct for kernel modules?

Modern kernel module loading splits executable sections (e.g., .text,
.init.text) into independently allocated memory regions. An offset relative
to a single module base address cannot reliably resolve to the correct memory
address.

Should this be defined as an in-section offset instead? Tools relying on this
documentation will calculate incorrect absolute addresses for inline sites in
loadable modules.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916074118.1007116-1-alan.maguire@oracle.com?part=11