Hi,
On 2/5/2025 7:17 AM, Alexei Starovoitov wrote:
> On Sat, Jan 25, 2025 at 10:59 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
>> From: Hou Tao <houtao1@xxxxxxxxxx>
>>
>> Add BPF_DYNPTR in btf_field_type to support bpf_dynptr in map key. The
>> parsing of bpf_dynptr in btf will be done in the following patch, and
>> the patch only adds two helpers: btf_new_bpf_dynptr_record() creates an
>> btf record which only includes a bpf_dynptr and btf_type_is_dynptr()
>> checks whether the btf_type is a bpf_dynptr or not.
>>
>> With the introduction of BPF_DYNPTR, BTF_FIELDS_MAX is changed from 11
>> to 13, therefore, update the hard-coded number in cpumask test as well.
>>
>> Signed-off-by: Hou Tao <houtao1@xxxxxxxxxx>
>> ---
>> include/linux/bpf.h | 5 ++-
>> include/linux/btf.h | 2 +
>> kernel/bpf/btf.c | 42 ++++++++++++++++---
>> .../selftests/bpf/progs/cpumask_common.h | 2 +-
>> 4 files changed, 43 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index feda0ce90f5a3..0ee14ae30100f 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -184,8 +184,8 @@ struct bpf_map_ops {
>> };
>>
>> enum {
>> - /* Support at most 11 fields in a BTF type */
>> - BTF_FIELDS_MAX = 11,
>> + /* Support at most 13 fields in a BTF type */
>> + BTF_FIELDS_MAX = 13,
> BTF_FIELDS_MAX doesn't need to be incremented when btf_field_type
> learns about a new type.
> The number of fields per map value is independent
> from a number of types that the verifier recognizes.
> The patch that incremented it last time slipped through
> by accident.
> Do you really need to increase it?
> If so, why 13 and not 32 ?
I see. There is no need to increase it for current patch set. The
original idea is that the parsing needs to support all of these special
field in the map key/value, but it is unnecessary. Will remove it.
> pw-bot: cr
