On 07/26, Martin KaFai Lau wrote:
Most of the codes in bpf_setsockopt(SOL_SOCKET) are duplicated from the sock_setsockopt(). The number of supported options are increasing ever and so as the duplicated codes.
One issue in reusing sock_setsockopt() is that the bpf prog has already acquired the sk lock. sockptr_t is useful to handle this. sockptr_t already has a bit 'is_kernel' to handle the kernel-or-user memory copy. This patch adds a 'is_bpf' bit to tell if sk locking has already been ensured by the bpf prog.
Why not explicitly call it is_locked/is_unlocked? I'm assuming, at some point,
we can have code paths in bpf where the socket has been already locked by the stack?
