From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivek Goyal Subject: Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path Date: Tue, 15 Apr 2014 20:20:10 -0400 Message-ID: <20140416002010.GA5035@redhat.com> References: <1397596546-10153-1-git-send-email-vgoyal@redhat.com> <1397596546-10153-3-git-send-email-vgoyal@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "linux-kernel@vger.kernel.org" , cgroups@vger.kernel.org, Network Development , "David S. Miller" , Tejun Heo , Simo Sorce , lpoetter@redhat.com, kay@redhat.com, dwalsh@redhat.com To: Andy Lutomirski Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, Apr 15, 2014 at 02:53:13PM -0700, Andy Lutomirski wrote: > On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal wrote: > > This patch implements socket option SO_PASSCGROUP along the lines of > > SO_PASSCRED. > > > > If SO_PASSCGROUP is set, then recvmsg() will get a control message > > SCM_CGROUP which will contain the cgroup path of sender. This cgroup > > belongs to first mounted hierarchy in the sytem. > > > > SCM_CGROUP control message can only be received and sender can not send > > a SCM_CGROUP message. Kernel automatically generates one if receiver > > chooses to receive one. > > > > This works both for unix stream and datagram sockets. > > > > cgroup information is passed only if either the sender or receiver has > > SO_PASSCGROUP option set. This means for existing workloads they should > > not see any significant performance impact of this change. > > This is odd. Shouldn't an SCM_CGROUP cmsg be generated when the > receiver has SO_PASSCGROUP set and the sender passes SCM_CGROUP to > sendmsg? How can receiver trust the cgroup info generated by sender. It needs to be generated by kernel so that receiver can trust it. And if receiver needs to know cgroup of sender, receiver can just set SO_PASSCGROUP on socket and receiver should get one SCM_CGROUP message with each message received. Thanks Vivek > > --Andy