[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1890f66fdb9341178202866cd20d4504@BY2PR03MB299.namprd03.prod.outlook.com>
Date: Thu, 9 Jan 2014 21:13:05 +0000
From: KY Srinivasan <kys@...rosoft.com>
To: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
Dan Carpenter <dan.carpenter@...cle.com>
CC: "olaf@...fle.de" <olaf@...fle.de>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"apw@...onical.com" <apw@...onical.com>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
Subject: RE: [PATCH 1/1] Drivers: hv: Implement the file copy service
> -----Original Message-----
> From: gregkh@...uxfoundation.org [mailto:gregkh@...uxfoundation.org]
> Sent: Thursday, January 09, 2014 12:15 PM
> To: Dan Carpenter
> Cc: KY Srinivasan; olaf@...fle.de; jasowang@...hat.com; linux-
> kernel@...r.kernel.org; apw@...onical.com; devel@...uxdriverproject.org
> Subject: Re: [PATCH 1/1] Drivers: hv: Implement the file copy service
>
> On Thu, Jan 09, 2014 at 11:09:21PM +0300, Dan Carpenter wrote:
> > We've had this discussion before where you urge me to trust the host...
> >
> > Problem: This code is racy.
> > Solution: The host will only send one message at a time.
> >
> > Now I have to audit the user space code on the host and I don't feel
> > like doing that so you win.
> >
> > I wish we had a better way to do IPC. If kdbus were ready, that might
> > have worked for this, and it's a better solution because both sender and
> > reciever code will be written in a less trusting way.
>
> kdbus is almost ready, it might make 3.15, depending on the result of
> work that is happening at linux.conf.au and FOSDEM.
>
> If it would be a better solution for this, that's even more reason to
> get kdbus merged soon, no need to add something that doesn't really
> work.
>
> But, how will kdbus help with this? It's a userspace <-> userspace
> message transmission bus, would you want the kernel to be a receiver or
> sender here?
Greg,
The transport between the kernel and the user in this driver is a regular char device and
Vmbus is the transport between the host and the guest. As you observe, I am not sure
how kdbus would be useful.
K. Y
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists