Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754436AbbGBUGx (ORCPT ); Thu, 2 Jul 2015 16:06:53 -0400 Received: from mail.codeweavers.com ([216.251.189.131]:35667 "EHLO mail.codeweavers.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752095AbbGBUGb (ORCPT ); Thu, 2 Jul 2015 16:06:31 -0400 Message-ID: <559599C5.9030902@codeweavers.com> Date: Thu, 02 Jul 2015 15:06:29 -0500 From: Jeremy White User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Alan Stern CC: Oliver Neukum , Hans de Goede , "Daniel P. Berrange" , spice-devel@lists.freedesktop.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP. References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2765 Lines: 56 On 07/02/2015 02:59 PM, Alan Stern wrote: > On Thu, 2 Jul 2015, Jeremy White wrote: > >>>> I don't follow that analysis. The usbip interactions with the usb stack >>>> all seem to be atomic, and never trigger a syscall, as far as I can >>>> tell. A port reset will flip a few bits and return. A urb enqueue >>>> queues and wakes a different thread, and returns. The alternate thread >>>> performs the sendmsg. >>>> >>>> I'm not suggesting that running a storage device over usbip is >>>> especially safe, but I don't see the limit on the design. >>> >>> Are you referring to the current code or the proposed user space pipe? >> >> I'm referring to current usbip code. But the proposed driver would have >> the same behavior. >> >> To be clear, I think the only tangible new proposal is the one Hans put >> forth, which would modify the driver I originally posted to use a >> netlink socket instead of a passing a file descriptor in via sysfs. >> That would allow the user space application responsible for initiating >> the request to provide TLS as desired. It comes with the expense of an >> extra memcpy, but I suspect Hans is right in saying the network >> latencies make that an irrelevant cost. > > Oliver is talking about the danger of having part of the communication > path for a block device run through userspace. > > Imagine a situation where the client uses a USB storage device provided > by the server as a swap device. And suppose a userspace daemon on the > client has to process USB packets as they pass between the client and > the server. If the daemon is idle for some time, parts of its address > space may get stored in the swap area on the server and paged out. > > Now consider what happens when those parts of memory need to be paged > back in. The client submits a request to read from the swap area. > The request is transformed into USB packets and sent through the > userspace daemon for transmission to the server. But the daemon can't > process the packets because it is waiting for its missing parts to be > paged back! Result: deadlock. Right. I followed that. Oliver also asserted that he believed that the current usbip implementation has this flaw; I do not follow that. The concept is that the usbip device driver virtualizes the device behavior; isolating the running kernel from the vagaries of the network transport. All proposed usbredir implementations, even if they move the network transport to user space, would retain that behavior. Cheers, Jeremy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/