On Thu, Jul 28, 2022 at 09:56:29AM -0700, Jakub Kicinski wrote: > 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. Yeah, I think I read the 'vote against @in_bpf' in the other way. :) Sure. I will do s/is_bpf/is_locked/ and do the in_bpf() context checking before ns_capable().
