Re: [PATCH bpf-next v2 06/20] bpf: Set BPF_INT_F_DYNPTR_IN_KEY conditionally

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 2/28/2025 5:10 AM, Alexei Starovoitov wrote:
> On Fri, Feb 14, 2025 at 9:30 AM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
>> On Thu, Feb 13, 2025 at 11:25 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
>>> Hi,
>>>

SNIP
>>>
>>> 3) ->map_check_btf()
>>>
>>> In ->map_check_btf() callback, check whether the created map is
>>> mismatched with the dynptr key. If it is, let map_create() destroys the map.
>> map_check_btf() itself can have the code to filter out unsupported maps
>> like it does already:
>>                         case BPF_WORKQUEUE:
>>                                 if (map->map_type != BPF_MAP_TYPE_HASH &&
>>                                     map->map_type != BPF_MAP_TYPE_LRU_HASH &&
>>                                     map->map_type != BPF_MAP_TYPE_ARRAY) {
>>                                         ret = -EOPNOTSUPP;
>>
>> I don't mind moving map_check_btf() before ->map_alloc_check()
>> since it doesn't really need 'map' pointer.
>> I objected to partial move where btf_get_by_fd() is done early
>> while the rest after map allocation.
>> Either all map types do map_check_btf() before alloc or
>> all map types do it after.
>>
>> If we move map_check_btf() before alloc
>> then the final map->ops->map_check_btf() should probably
>> stay after alloc.
>> Otherwise this is too much churn.
>>
>> So I think it's better to try to keep the whole map_check_btf() after
>> as it is right now.
>> I don't see yet why dynptr-in-key has to have it before.
>> So far map_extra limitation was the only special condition,
>> but even if we have to keep (which I doubt) it can be done in
>> map->ops->map_check_btf().
> Any update on this ?
> Two weeks have passed.
> iirc above was the only thing left to resolve.
Er, I started adding bpffs seq-file and batched operation support
recently.  I need to ask whether it is OK to complete these todo items
shown below in the following patch-set. As noted in the cover letter,
the following things have not been supported yet:

1) batched map operation through bpf syscall
2) the memory accounting for dynptr (aka .htab_map_mem_usage)
3) btf print for the dynptr in map key
4) bpftool support
5) the iteration of elements through bpf program





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux