On 24.07.20 07:31, Martin KaFai Lau wrote: > On Thu, Jul 23, 2020 at 01:50:26PM +0200, KP Singh wrote: >> From: KP Singh <kpsi...@google.com> >> >> A purely mechanical change to split the renaming from the actual >> generalization. >> >> Flags/consts: >> >> SK_STORAGE_CREATE_FLAG_MASK BPF_LOCAL_STORAGE_CREATE_FLAG_MASK >> BPF_SK_STORAGE_CACHE_SIZE BPF_LOCAL_STORAGE_CACHE_SIZE >> MAX_VALUE_SIZE BPF_LOCAL_STORAGE_MAX_VALUE_SIZE >> >> Structs: >> >> bucket bpf_local_storage_map_bucket >> bpf_sk_storage_map bpf_local_storage_map >> bpf_sk_storage_data bpf_local_storage_data >> bpf_sk_storage_elem bpf_local_storage_elem >> bpf_sk_storage bpf_local_storage >> selem_linked_to_sk selem_linked_to_storage >> selem_alloc bpf_selem_alloc >> >> The "sk" member in bpf_local_storage is also updated to "owner" >> in preparation for changing the type to void * in a subsequent patch. >> >> Functions: >> >> __selem_unlink_sk bpf_selem_unlink_storage >> __selem_link_sk bpf_selem_link_storage >> selem_unlink_sk __bpf_selem_unlink_storage >> sk_storage_update bpf_local_storage_update >> __sk_storage_lookup bpf_local_storage_lookup >> bpf_sk_storage_map_free bpf_local_storage_map_free >> bpf_sk_storage_map_alloc bpf_local_storage_map_alloc >> bpf_sk_storage_map_alloc_check bpf_local_storage_map_alloc_check >> bpf_sk_storage_map_check_btf bpf_local_storage_map_check_btf > Thanks for separating this mechanical name change in a separate patch. > It is much easier to follow. This patch looks good. > > A minor thought is, when I look at unlink_map() and unlink_storage(), > it keeps me looking back for the lock situation. I think > the main reason is the bpf_selem_unlink_map() is locked but > bpf_selem_unlink_storage() is unlocked now. May be: > > bpf_selem_unlink_map() => bpf_selem_unlink_map_locked() > bpf_selem_link_map() => bpf_selem_link_map_locked() > __bpf_selem_unlink_storage() => bpf_selem_unlink_storage_locked() > bpf_link_storage() means unlocked > bpf_unlink_storage() means unlocked. > > I think it could be one follow-up patch later instead of interrupting > multiple patches in this set for this minor thing. For now, lets > continue with this and remember default is nolock for storage. > Makes sense. I can update these in a separate patch if there are no major changes needed in this one. > I will continue tomorrow. Awesome! Thanks :) - KP >
