On Fri, Jun 21, 2019 at 04:05:24PM -0400, Alan Stern wrote:
> On Sat, 22 Jun 2019, Suwan Kim wrote:
>
> > There are bugs on vhci with usb 3.0 storage device. Originally, vhci
> > doesn't supported SG. So, USB storage driver on vhci divides SG list
> > into multiple URBs and it causes buffer overflow on the xhci of the
> > server. So we need to add SG support to vhci
>
> It doesn't cause buffer overflow. The problem was that a transfer got
> terminated too early because the transfer length for one of the URBs
> was not divisible by the maxpacket size.
Oh.. I misunderstood the problem. I will rewrite the problem
situation.
> > In this patch, vhci basically support SG and it sends each SG list
> > entry to the stub driver. Then, the stub driver sees total length of
> > the buffer and allocates SG table and pages according to the total
> > buffer length calling sgl_alloc(). After the stub driver receives
> > completed URB, it again sends each SG list entry to the vhci.
> >
> > If HCD of server doesn't support SG, the stub driver allocates
> > big buffer using kmalloc() instead of using sgl_alloc() which
> > allocates SG list and pages.
>
> You might be better off not using kmalloc. It's easier for the kernel
> to allocate a bunch of small buffers than a single big one. Then you
> can create a separate URB for each buffer.
Ok. I will implement it as usb_sg_init() does and send v2 patch
including the logic of submitting separate URBs.
> > Alan fixed vhci bug with the USB 3.0 storage device by modifying
> > USB storage driver.
> > ("usb-storage: Set virt_boundary_mask to avoid SG overflows")
> > But the fundamental solution of it is to add SG support to vhci.
> >
> > This patch works well with the USB 3.0 storage devices without Alan's
> > patch, and we can revert Alan's patch if it causes some troubles.
>
> These last two paragraphs don't need to be in the patch description.
I will remove these paragraphs in v2 patch.
> > Signed-off-by: Suwan Kim <suwan.kim027@xxxxxxxxx>
> > ---
>
> I'm not sufficiently familiar with the usbip drivers to review most of
> this. However...
>
> > diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> > index be87c8a63e24..cc93c1a87a3e 100644
> > --- a/drivers/usb/usbip/vhci_hcd.c
> > +++ b/drivers/usb/usbip/vhci_hcd.c
> > @@ -696,7 +696,8 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flag
> > }
> > vdev = &vhci_hcd->vdev[portnum-1];
> >
> > - if (!urb->transfer_buffer && urb->transfer_buffer_length) {
> > + if (!urb->transfer_buffer && !urb->num_sgs &&
> > + urb->transfer_buffer_length) {
> > dev_dbg(dev, "Null URB transfer buffer\n");
> > return -EINVAL;
> > }
> > @@ -1142,6 +1143,11 @@ static int vhci_setup(struct usb_hcd *hcd)
> > hcd->speed = HCD_USB3;
> > hcd->self.root_hub->speed = USB_SPEED_SUPER;
> > }
> > +
> > + /* support sg */
> > + hcd->self.sg_tablesize = ~0;
> > + hcd->self.no_sg_constraint = 1;
>
> You probably shouldn't do this, for two reasons. First, sg_tablesize
> of the server's HCD may be smaller than ~0. If the client's value is
> larger than the server's, a transfer could be accepted on the client
> but then fail on the server because the SG list was too big.
>
> Also, you may want to restrict the size of SG transfers even further,
> so that you don't have to allocate a tremendous amount of memory all at
> once on the server. An SG transfer can be quite large. I don't know
> what a reasonable limit would be -- 16 perhaps?
Is there any reason why you think that 16 is ok? Or Can I set this
value as the smallest value of all HC? I think that sg_tablesize
cannot be a variable value because vhci interacts with different
machines and all machines has different sg_tablesize value.
Regards
Suwan Kim
