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.