On 27/10/2023 02:35, Jakub Kicinski wrote:
On Fri, 27 Oct 2023 00:29:29 +0100 Vadim Fedorenko wrote:
Does anything prevent them from being used simultaneously
by difference CPUs?
The algorithm configuration and the key can be used by different CPUs
simultaneously
Makes sense, got confused ctx vs req. You allocate req on the fly.
+ case BPF_DYNPTR_TYPE_SKB:
+ return skb_pointer_if_linear(ptr->data, ptr->offset, __bpf_dynptr_size(ptr));
dynptr takes care of checking if skb can be written to?
dynptr is used to take care of size checking, but this particular part is used
to provide plain buffer from skb. I'm really sure if we can (or should) encrypt
or decrypt in-place, so API now assumes that src and dst are different buffers.
Not sure this answers my question. What I'm asking is basically whether
for destination we need to call __bpf_dynptr_is_rdonly() or something
already checks that.
ah, good point. I'm not sure how to make it better. the
__bpf_dynptr_data_ptr() code is based on bpf_dynptr_slice() which has
bpf_dynptr_slice_rdwr() variant. I don't think it's good idea to add
local rdwr variant. I can either add 2 parameter to force checking if
dynptr isn't read-only, or I can convert bpf_dynptr_slice* functions to
be wrappers over __bpf_dynptr_slice and reuse it in this code.
