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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
