On Wed, May 28, 2025 at 9:17 AM Jiayuan Chen <jiayuan.c...@linux.dev> wrote: > > A previous commit expanded the usage scope of bpf_get_cgroup_classid() to > all contexts (see Fixes tag), but this was inappropriate. > > First, syzkaller reported a bug [1]. > Second, it uses skb as an argument, but its implementation varies across > different bpf prog types. For example, in sock_filter and sock_addr, it > retrieves the classid from the current context > (bpf_get_cgroup_classid_curr_proto) instead of from skb. In tc egress and > lwt, it fetches the classid from skb->sk, but in tc ingress, it returns 0. > > In summary, the definition of bpf_get_cgroup_classid() is ambiguous and > its usage scenarios are limited. It should not be treated as a > general-purpose helper. This patch reverts part of the previous commit.
I think it's better to make it generic enough instead of reintroducing a bunch of prog specific proto handlers. See this discussion: https://lore.kernel.org/bpf/20250528020755.33182-1-yangfeng59...@163.com/ pw-bot: cr
