Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754330AbbGCIv0 (ORCPT ); Fri, 3 Jul 2015 04:51:26 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:55705 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751615AbbGCIvQ (ORCPT ); Fri, 3 Jul 2015 04:51:16 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-45-55964d01a81d Message-id: <55964CFF.1090803@samsung.com> Date: Fri, 03 Jul 2015 10:51:11 +0200 From: Krzysztof Opasiak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-version: 1.0 To: Alan Stern , Jeremy White 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; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsVy+t/xa7qMvtNCDX6+ELR482YNk8Wb49OZ LC6fnMtocXnXHDaLRctamS26Hq9ks1i/aT6zxYTfF9gcODy+XG1k8rjffZzJ4/2+q2wes+/+ YPRYv+Uqi8fnTXIBbFFcNimpOZllqUX6dglcGUuXzGEq2CZU0fSAu4HxKl8XIyeHhICJxKqO q0wQtpjEhXvr2boYuTiEBJYySjz+N5EVwnnOKLHgxjFWkCpeAS2Jh/M+soPYLAKqEp23HrJ0 MXJwsAnoS8zbJQoSFhWIkJh/7DUzRLmgxI/J91hAbBGBYImVB1cygsxkFrjKKHFj2yOwzcIC RRJzXmxnA7GFBHwkJhy9ADaTU8BX4sKcEJAws4CtxIL361ggbHmJzWveMk9gFJiFZMUsJGWz kJQtYGRexSiaWppcUJyUnmuoV5yYW1yal66XnJ+7iRES9l92MC4+ZnWIUYCDUYmH98LpqaFC rIllxZW5hxglOJiVRHg1XaaFCvGmJFZWpRblxxeV5qQWH2KU5mBREuedu+t9iJBAemJJanZq akFqEUyWiYNTqoGRa5PW+dNLOpf9jdh187Lt65PbF73v3TrfU3/LLQXTmj2pa9d8/m10dEHR hVlt1Xc2/A0+EWr7KONTk4LqqVCgO5Wu9odNfPm1UuKsWMrO1lWeDNfeThH2CWt9e333D0Y/ tYKMK2+ZT637L2oWdOpC2qRiUX+npKpK1dZJv5qmP3535dYBSbNqJZbijERDLeai4kQAwziK P3cCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2556 Lines: 56 On 07/02/2015 10:20 PM, Alan Stern wrote: > On Thu, 2 Jul 2015, Jeremy White wrote: > >>> 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. > > The point is that a device driver like usbip _cannot_ isolate the > running kernel from the vagaries of the network transport if part of > that transport occurs in userspace. > > If any part of the transport passes through userspace, you can end up > in a situation like what I outlined above, where a message can't be > transported until after its reply has been received. There's no way > for a device driver to prevent a deadlock when this occurs, no matter > what it virtualizes. > Doesn't we have the same problem with functionfs/gadgetfs and dummy_hcd? Or with fuse? It's a very generic problem for all "virtualized devices" and it is known for quite a long time. This is why many tutorials about swap warns that swap should be set up only on real block devices which are fully served in kernel. -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- 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/