On 06/06/2019 09:53 PM, Roman Gushchin wrote: > On Thu, Jun 06, 2019 at 09:39:35PM +0200, Daniel Borkmann wrote: >> On 06/06/2019 09:08 PM, Roman Gushchin wrote: >>> On Thu, Jun 06, 2019 at 11:59:11AM -0700, Roman Gushchin wrote: >>>> Currently bpf_get_current_cgroup_id() is not supported for >>>> CGROUP_SKB programs. An attempt to load such a program generates an >>>> error like this: >>>> libbpf: >>>> 0: (b7) r6 = 0 >>>> ... >>>> 8: (63) *(u32 *)(r10 -28) = r6 >>>> 9: (85) call bpf_get_current_cgroup_id#80 >>>> unknown func bpf_get_current_cgroup_id#80 >>>> >>>> There are no particular reasons for denying it, >>>> and we have some use cases where it might be useful. >>> >>> Ah, sorry, it's not so simple, as we probably need to take >>> the cgroup pointer from the socket, not from current. >>> >>> So the implementation of the helper should be different >>> for this type of programs. >>> >>> So I wonder if it's better to introduce a new helper >>> bpf_get_sock_cgroup_id()? >>> >>> What do you think? >> >> We do have bpf_skb_cgroup_id(), did you give that a try? > > It also isn't supported for CGROUP_SKB, but other than that looks > exactly what I need. > > Thank you for pointing at it! Yes, the helper would need to be enabled there. Cheers, Daniel
