Hello. On Sun, Mar 09, 2025 at 02:28:11PM +0100, Alexander Mikhalitsyn <aleksandr.mikhalitsyn@xxxxxxxxxxxxx> wrote: > As we don't add any new state to the socket itself there is no potential locking issues > or performance problems. We use already existing sk->sk_cgrp_data. This is the cgroup where the socket was created in. If such a socket is fd-passed to another cgroup, SO_PEERCGROUPID may not be what's expected. > We already have analogical interfaces to retrieve this > information: > - inet_diag: INET_DIAG_CGROUP_ID > - eBPF: bpf_sk_cgroup_id > > Having getsockopt() interface makes sense for many applications, because using eBPF is > not always an option, while inet_diag has obvious complexety and performance drawbacks > if we only want to get this specific info for one specific socket. I'm not that familiar with INET_DIAG_CGROUP_ID but that one sounds like fit for the purpose of obtaining socket creator's cgroup whereas what is desired here is slightly different thing -- cgroup of actual sender through the socket. > Idea comes from UAPI kernel group: > https://uapi-group.org/kernel-features/ In theory shortlived (sending) program may reside in shortlived cgroup and the consumer of SO_PEERCGROUPID (even if it is real sender) would only have that number to work with. It doesn't guarantee existence of original cgroup or stable translation to cgroup path. I think having something like this could be useful but consumers must still be aware of limitations (and possible switch from path-oriented to id-oriented work with cgroups). Thanks, Michal
Attachment:
signature.asc
Description: PGP signature
