From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 094E3C53A for ; Fri, 24 Jun 2016 09:44:00 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 24 Jun 2016 00:44:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,518,1459839600"; d="scan'208";a="724345082" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by FMSMGA003.fm.intel.com with ESMTP; 24 Jun 2016 00:43:58 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 24 Jun 2016 08:43:30 +0100 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.145]) by IRSMSX156.ger.corp.intel.com ([10.108.20.68]) with mapi id 14.03.0248.002; Fri, 24 Jun 2016 08:43:30 +0100 From: "Loftus, Ciara" To: Yuanhan Liu , Aaron Conole CC: "dev@dpdk.org" , "Xie, Huawei" , Christian Ehrhardt Thread-Topic: [RFC] librte_vhost: Add unix domain socket fd registration Thread-Index: AQHRzcBK27iMSKEFc0Wb3aZQx33EaJ/4O/sA Date: Fri, 24 Jun 2016 07:43:29 +0000 Message-ID: <74F120C019F4A64C9B78E802F6AD4CC24F8E0AA7@IRSMSX106.ger.corp.intel.com> References: <1466177556-14891-1-git-send-email-aconole@redhat.com> <20160621072128.GK23111@yliu-dev.sh.intel.com> <87r3bqn0o8.fsf@trashheap.bytheb.org> <20160624023105.GS23111@yliu-dev.sh.intel.com> In-Reply-To: <20160624023105.GS23111@yliu-dev.sh.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTA4MGQ4NDItN2EzMC00MzA5LTlhZDYtOTYxZDQxMWEzNTI1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ijk1NXQrQTlsK0hZTlM4MGNLVE5jcjA1Ym9Sc3hmMlB3NGdiOE56M08xRDA9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] librte_vhost: Add unix domain socket fd registration X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 07:44:01 -0000 >=20 > On Tue, Jun 21, 2016 at 09:15:03AM -0400, Aaron Conole wrote: > > Yuanhan Liu writes: > > > > > On Fri, Jun 17, 2016 at 11:32:36AM -0400, Aaron Conole wrote: > > >> Prior to this commit, the only way to add a vhost-user socket to the > > >> system is by relying on librte_vhost to open the unix domain socket = and > > >> add it to the unix socket list. This is problematic for application= s > > >> which would like to set the permissions, > > > > > > So, you want to address the issue raised by following patch? > > > > > > http://dpdk.org/dev/patchwork/patch/12222/ > > > > That patch does try to address the issue, however - it has some > > problems. The biggest is a TOCTTOU issue when using chown. The way to > > solve that issue properly is different depending on which operating > > system is being used (for instance, FreeBSD doesn't honor > > fchown(),fchmod() on file descriptors). My solution is basically to > > punt that responsibility to the controlling application. > > > > > I would still like to stick to my proposal, that is to introduce a > > > new API to do the permission change at anytime, if we end up with > > > wanting to introduce a new API. > > > > I've spent a lot of time looking at the TOCTTOU problem, and I think > > that is a really hard problem to solve portably. Might be good to just > > start with the flexible mechanism here that lets the application > > developer satisfy their own needs. > > > > >> or applications which are not > > >> directly allowed to open sockets due to policy restrictions. > > > > > > Could you name a specific example? > > > > SELinux policy might require one application to open the socket, and > > pass it back via a dbus mechanism. I can't actually think of a concret= e > > implemented case, so it may not be valid. > > > > > BTW, JFYI, since 16.07, DPDK supports client mode. It's QEMU (acting > > > as the server) will create the socket file. I guess that would dimini= sh > > > (or even avoid?) the permission pain that DPDK acting as server bring= s. > > > I doubt the API to do the permission change is really needed then. > > > > I wouldn't say it 'solves' the issue so much as hopes no one uses serve= r > > mode in DPDK. I agree, for OvS, it could. >=20 > Actually, I think I would (personally) suggest people to switch to DPDK > vhost-user client mode, for two good reasons: >=20 > - it should solve the socket permission issue raised by you and Christian= . >=20 > - it has the "reconnect" feature since 16.07. Which means guest network > will still work from a DPDK vhost-user restart/crash. DPDK vhost-user > as server simply doesn't support that. >=20 > And FYI, Loftus is doing the DPDK for OVS intergration. Not quite sure > whether she put the client mode as the default mode though. Hi Yuanhan, I intend to keep the DPDK server-mode as the default. My reasoning is that = not all users will have access to QEMU v2.7.0 initially. We will keep operating= as before but have an option to switch to DPDK client mode, and then perhaps look at switching the default in a later release. Thanks, Ciara >=20 > > Thanks so much for your thoughts and review on this, Yuanhan Liu! >=20 > Thank you for proposing ideas to make DPDK better! >=20 > --yliu