Re: [Spice-devel] [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux