Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754826AbbGCOFB (ORCPT ); Fri, 3 Jul 2015 10:05:01 -0400 Received: from netrider.rowland.org ([192.131.102.5]:49653 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932140AbbGCOEz (ORCPT ); Fri, 3 Jul 2015 10:04:55 -0400 Date: Fri, 3 Jul 2015 10:04:54 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Krzysztof Opasiak cc: Jeremy White , Oliver Neukum , Hans de Goede , "Daniel P. Berrange" , , , Subject: Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP. In-Reply-To: <55964CFF.1090803@samsung.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1189 Lines: 32 On Fri, 3 Jul 2015, Krzysztof Opasiak wrote: > > 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? Yes indeed. > 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. That is good advice. :-) Alan Stern -- 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/