Re: Question: Is it OK to assume the address of bpf_dynptr_kern will be 8-bytes aligned and reuse the lowest bits to save extra info ?

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

 



Hi,

On 8/22/2023 11:25 AM, Alexei Starovoitov wrote:
> On Mon, Aug 21, 2023 at 6:46 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
>> Hi,
>>
>> On 8/22/2023 8:58 AM, Alexei Starovoitov wrote:
>>> On Mon, Aug 21, 2023 at 5:55 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
>>>> Hi,
>>>>
>>>> On 8/22/2023 7:49 AM, Alexei Starovoitov wrote:
>>>>> On Sat, Aug 19, 2023 at 3:39 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 8/18/2023 7:00 AM, Alexei Starovoitov wrote:
>>>>>>> On Wed, Aug 16, 2023 at 11:35 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
>>>>>>>
>> SNIP
>>>>>>> If the existing bpf_map_lookup_elem() helper doesn't fit qp-tree we can
>>>>>>> use new kfuncs from bpf prog and LPM-like map accessors from syscall.
>>>>>> It is a feasible solution, but it will make qp-trie be different with
>>>>>> other map types. I will try to extend the APIs in bpf_map_ops first to
>>>>>> see how much churns it may introduce.
>>>>> you mean you want to try to dynamically adapt bpf_map_lookup_elem()
>>>>> to consider 'void *key' as a pointer to dynptr for bpf prog and
>>>>> lpm-like tuple for syscall?
>>>>> I'm afraid the verifier changes will be messy, since PTR_TO_MAP_KEY is
>>>>> quite special.
>>>> No. I didn't plan to do that. I am trying to add three new APIs in
>>>> bpf_map_ops to handle lookup/update/delete operation from bpf syscall
>>>> (e.g, map_lookup_elem_syscall). So bpf program and bpf syscall can use
>>>> different API to operate on qp-trie.
>>> How does bpf prog side api look like?
>>> I thought we wanted to use dynptr as a key?
>> Yes. bpf prog will use dynptr as the map key. The bpf program will use
>> the same map helpers as hash map to operate on qp-trie and the verifier
>> will be updated to allow using dynptr as map key for qp-trie.
> And that's the problem I just mentioned.
> PTR_TO_MAP_KEY is special. I don't think we should hack it to also
> mean ARG_PTR_TO_DYNPTR depending on the first argument (map type).

Sorry for misunderstanding your reply. But before switch to the kfunc
way, could you please point me to some code or function which shows the
specialty of PTR_MAP_KEY ?





[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