Subject: Re: [PATCH bpf-next 02/14] bpf: net: Avoid sock_setsockopt() taking sk lock when called from bpf

From: Jakub Kicinski <[email-masked]>
Date: Thu, 28 Jul 2022 09:56:29 -0700

On Thu, 28 Jul 2022 09:31:04 -0700 Martin KaFai Lau wrote:
> If I understand the concern correctly, it may not be straight forward to
> grip the reason behind the testings at in_bpf() [ the in_task() and
> the current->bpf_ctx test ] ?  Yes, it is a valid point.
> 
> The optval.is_bpf bit can be directly traced back to the bpf_setsockopt
> helper and should be easier to reason about.

I think we're saying the opposite thing. in_bpf() the context checking
function is fine. There is a clear parallel to in_task() and combined
with the capability check it should be pretty obvious what the code
is intending to achieve.

sockptr_t::in_bpf which randomly implies that the lock is already held
will be hard to understand for anyone not intimately familiar with the
BPF code. Naming that bit is_locked seems much clearer.

Which is what I believe Stan was proposing.