summaryrefslogtreecommitdiffstats
path: root/drivers/usb/usbip/stub_tx.c
AgeCommit message (Collapse)Author
2019-10-04usbip: clean up an indentation issueColin Ian King
There is a return statement that is indented incorrectly, fix this. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20190927092000.19373-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-03usbip: Implement SG support to vhci-hcd and stub driverSuwan Kim
There are bugs on vhci with usb 3.0 storage device. In USB, each SG list entry buffer should be divisible by the bulk max packet size. But with native SG support, this problem doesn't matter because the SG buffer is treated as contiguous buffer. But without native SG support, USB storage driver breaks SG list into several URBs and the error occurs because of a buffer size of URB that cannot be divided by the bulk max packet size. The error situation is as follows. When USB Storage driver requests 31.5 KB data and has SG list which has 3584 bytes buffer followed by 7 4096 bytes buffer for some reason. USB Storage driver splits this SG list into several URBs because VHCI doesn't support SG and sends them separately. So the first URB buffer size is 3584 bytes. When receiving data from device, USB 3.0 device sends data packet of 1024 bytes size because the max packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes. But the first URB buffer has only 3584 bytes buffer size. So host controller terminates the transfer even though there is more data to receive. So, vhci needs to support SG transfer to prevent this error. In this patch, vhci supports SG regardless of whether the server's host controller supports SG or not, because stub driver splits SG list into several URBs if the server's host controller doesn't support SG. To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags if URB has SG list and this flag will tell stub driver to use SG list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG flag to avoid unnecessary DMA unmapping in HCD. vhci sends each SG list entry to stub driver. Then, stub driver sees the total length of the buffer and allocates SG table and pages according to the total buffer length calling sgl_alloc(). After stub driver receives completed URB, it again sends each SG list entry to vhci. If the server's host controller doesn't support SG, stub driver breaks a single SG request into several URBs and submits them to the server's host controller. When all the split URBs are completed, stub driver reassembles the URBs into a single return command and sends it to vhci. Moreover, in the situation where vhci supports SG, but stub driver does not, or vice versa, usbip works normally. Because there is no protocol modification, there is no problem in communication between server and client even if the one has a kernel without SG support. In the case of vhci supports SG and stub driver doesn't, because vhci sends only the total length of the buffer to stub driver as it did before the patch applied, stub driver only needs to allocate the required length of buffers using only kmalloc() regardless of whether vhci supports SG or not. But stub driver has to allocate buffer with kmalloc() as much as the total length of SG buffer which is quite huge when vhci sends SG request, so it has overhead in buffer allocation in this situation. If stub driver needs to send data buffer to vhci because of IN pipe, stub driver also sends only total length of buffer as metadata and then sends real data as vhci does. Then vhci receive data from stub driver and store it to the corresponding buffer of SG list entry. And for the case of stub driver supports SG and vhci doesn't, since the USB storage driver checks that vhci doesn't support SG and sends the request to stub driver by splitting the SG list into multiple URBs, stub driver allocates a buffer for each URB with kmalloc() as it did before this patch. * Test environment Test uses two difference machines and two different kernel version to make mismatch situation between the client and the server where vhci supports SG, but stub driver does not, or vice versa. All tests are conducted in both full SG support that both vhci and stub support SG and half SG support that is the mismatch situation. Test kernel version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of guestimating DMA capabilities" to avoid unnecessary DMA mapping and unmapping. - Test kernel version - 5.3-rc6 with SG support - 5.1.20-200.fc29.x86_64 without SG support * SG support test - Test devices - Super-speed storage device - SanDisk Ultra USB 3.0 - High-speed storage device - SMI corporation USB 2.0 flash drive - Test description Test read and write operation of mass storage device that uses the BULK transfer. In test, the client reads and writes files whose size is over 1G and it works normally. * Regression test - Test devices - Super-speed device - Logitech Brio webcam - High-speed device - Logitech C920 HD Pro webcam - Full-speed device - Logitech bluetooth mouse - Britz BR-Orion speaker - Low-speed device - Logitech wired mouse - Test description Moving and click test for mouse. To test the webcam, use gnome-cheese. To test the speaker, play music and video on the client. All works normally. * VUDC compatibility test VUDC also works well with this patch. Tests are done with two USB gadget created by CONFIGFS USB gadget. Both use the BULK pipe. 1. Serial gadget 2. Mass storage gadget - Serial gadget test Serial gadget on the host sends and receives data using cat command on the /dev/ttyGS<N>. The client uses minicom to communicate with the serial gadget. - Mass storage gadget test After connecting the gadget with vhci, use "dd" to test read and write operation on the client side. Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1 Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1 Signed-off-by: Suwan Kim <suwan.kim027@gmail.com> Acked-by: Shuah khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-19usbip: stub: stop printing kernel pointer addresses in messagesShuah Khan
Remove and/or change debug, info. and error messages to not print kernel pointer addresses. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-08usbip: fix stub_send_ret_submit() vulnerability to null transfer_bufferShuah Khan
stub_send_ret_submit() handles urb with a potential null transfer_buffer, when it replays a packet with potential malicious data that could contain a null buffer. Add a check for the condition when actual_length > 0 and transfer_buffer is null. Reported-by: Secunia Research <vuln@secunia.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-07USB: usbip: Remove redundant license textGreg Kroah-Hartman
Now that the SPDX tag is in all USB files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Valentina Manea <valentina.manea.m@gmail.com> Acked-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-04USB: add SPDX identifiers to all remaining files in drivers/usb/Greg Kroah-Hartman
It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/usb/ and include/linux/usb* files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-13usb: usbip: set buffer pointers to NULL after freeMichael Grzeschik
The usbip stack dynamically allocates the transfer_buffer and setup_packet of each urb that got generated by the tcp to usb stub code. As these pointers are always used only once we will set them to NULL after use. This is done likewise to the free_urb code in vudc_dev.c. This patch fixes double kfree situations where the usbip remote side added the URB_FREE_BUFFER. Cc: stable@vger.kernel.org Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-28usbip: safe completion against unbind operationNobuo Iwata
This patch adds a code fragment to ignore completing URBs in closing connection. Regarding this patch, 2 execution contexts are related. 1) stub_tx.c: stub_complete() which is called from USB core 1-1) add to unlink list and free URB or 1-2) move to tx list 2) stub_dev.c: stub_shutdown_connection() which is invoked by unbind operation through sysfs. 2-1) stop TX/RX threads 2-2) close TCP connection and set ud.tcp_socket to NULL 2-3) cleanup pending URBs by stub_device_cleanup_urbs(sdev) 2-4) free unlink list (no lock) In the race condition, URBs which will be cleared in 2-3) may be handled in 1). In case 1-1), it will not be transferred bcause tx threads are stooped in 2-1). In case 1-2), may be freed in 2-4). With this patch, after 2-2), completing URBs in 1) will not be handled and cleared in 2-3). The kernel log with this patch is as below. kernel: usbip_core: usbip_kernel_unlink:792: shutting down tcp_socket ef61d980 kernel: usbip-host 1-3: free sdev f5df6180 kernel: usbip-host 1-3: free urb f5df6700 kernel: usbip-host 1-3: Enter kernel: usbip_core: usbip_stop_eh:132: usbip_eh waiting completion 5 kernel: usbip_host: stub_complete:71: complete! status 0 kernel: usbip_host: stub_complete:102: ignore urb for closed connection e725fc00 (*) kernel: usbip_host: stub_complete:71: complete! status -2 kernel: usbip-host 1-3: stopped by a call to usb_kill_urb() because of cleaning up a virtual connection kernel: usbip-host 1-3: free urb e725fc00 (**) kernel: usbip-host 1-3: free urb e725e000 kernel: usbip_host: stub_complete:71: complete! status -2 kernel: usbip-host 1-3: stopped by a call to usb_kill_urb() because of cleaning up a virtual connection kernel: usbip-host 1-3: free urb e725f800 kernel: usbip_host: stub_complete:71: complete! status -2 kernel: usbip-host 1-3: stopped by a call to usb_kill_urb() because of cleaning up a virtual connection kernel: usbip-host 1-3: free urb e725e800 kernel: usbip_host: stub_complete:71: complete! status -2 kernel: usbip-host 1-3: stopped by a call to usb_kill_urb() because of cleaning up a virtual connection kernel: usbip-host 1-3: device reset kernel: usbip-host 1-3: lock for reset kernel: usbip_host: store_match_busid:178: del busid 1-3 kernel: uvcvideo: Found UVC 1.00 device Venus USB2.0 Camera (056e:700a) kernel: input: Venus USB2.0 Camera as /devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3:1.0/input/input22 (*) skipped with this patch in completion (**) released in 2-3 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-28usbip: fix NULL pointer dereference on errorsAlexander Popov
Fix NULL pointer dereference and obsolete comments forgotten when usbip server was converted from an interface driver to a device driver. Signed-off-by: Alexander Popov <alpopov@ptsecurity.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-08-25usbip: move usbip kernel code out of stagingValentina Manea
At this point, USB/IP kernel code is fully functional and can be moved out of staging. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>