Hi!
Here's a small report including the script to reproduce.
Test environment:
QEMU/KVM Virtual Machine with Fedora 38 Workstation x86-64
Kernel: 6.4.0-0.rc4.20230604gte5282a7d.339.vanilla.fc38.x86_64
from mainline repo
usbip user-space package:
Name : usbip
Version : 5.7.9
Release : 8.fc38
Architecture : x86_64
Size : 164 k
Source : usbip-5.7.9-8.fc38.src.rpm
USB devices: two USB sticks passed to the VM, busid 1-5 and 1-6
usbipd and usbip attach commands are called on the same host.
Set up commands:
=====================
modprobe usbip_host
modprobe vhci_hcd
usbip bind -b 1-5
usbip bind -b 1-6
=====================
Start usbipd server:
=====================
usbipd
=====================
Test script:
=====================
#!/bin/bash
# This script tries to trigger the race condition during two parallel
calls of the usbip attach command.
while true; do
usbip attach -r localhost -b 1-5 &
# comment out this sleep to trigger race condition
sleep 2
usbip attach -r localhost -b 1-6 &
wait
echo "usbip attach called twice"
# comment out this sleep to see usbip port command fail
sleep 1
check_attach="$(usbip port | wc -l)"
if [[ ! $check_attach =~ "10" ]]; then
echo "usbip port failed"
usbip port
break
fi
usbip detach -p 0
usbip detach -p 1
# comment out this sleep to see usbip port command fail
sleep 1
check_detach="$(usbip port | wc -l)"
if [[ ! $check_detach =~ "2" ]]; then
echo "usbip detach or usbip port failed"
break
fi
done
=====================
Test results:
1. With all three sleeps uncommented we observer the correct output:
the infinite loop repeats printing
===================== script output start ==============
usbip attach called twice
usbip: info: Port 0 is now detached!
usbip: info: Port 1 is now detached!
===================== script output end ===============
which means that we can attach and detach devices as many times as we want.
usbip port shows correct number of usbip devices
==================== usbip port output start ====================
[root@localhost-live ~]# usbip port
Imported USB devices
====================
Port 00: <Port in Use> at High Speed(480Mbps)
Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)
: unknown product (090c:2000)
3-1 -> usbip://localhost:3240/1-5
-> remote bus/dev 001/004
Port 01: <Port in Use> at High Speed(480Mbps)
unknown vendor : unknown product (0000:7777)
3-2 -> usbip://localhost:3240/1-6
-> remote bus/dev 001/005
====================== usbip port output end ===================
2. Comment out the first sleep and you will get race condition. The
script hangs since one of the
usbip attach commands is stuck in its inner infinite loop and the same
message is repeated in dmesg output:
===================== dmesg ===========================
[ 691.760921] vhci_hcd vhci_hcd.0: port 0 already used
[ 691.761022] vhci_hcd vhci_hcd.0: port 0 already used
[ 691.761428] vhci_hcd vhci_hcd.0: port 0 already used
[ 691.761553] vhci_hcd vhci_hcd.0: port 0 already used
[ 691.761752] vhci_hcd vhci_hcd.0: port 0 already used
[ 691.761892] vhci_hcd vhci_hcd.0: port 0 already used
===================== dmesg ===========================
usbipd does not know about the client issue and prints the following
as nothing happened:
====================== usbipd output start ==========================
usbipd: info: connection from ::1:42928
usbipd: info: connection from ::1:42942
usbipd: info: received request: 0x8003(5)
usbipd: info: found requested device: 1-5
usbipd: info: received request: 0x8003(5)
usbipd: info: found requested device: 1-6
usbip: info: connect: 1-5
usbipd: info: request 0x8003(5): complete
usbip: info: connect: 1-6
usbipd: info: request 0x8003(5): complete
======================= usbipd output end =============================
usbip port command shows only one device attached to the client:
======================= usbip port output start ==============================
[root@localhost-live ~]# usbip port
Imported USB devices
====================
Port 00: <Port in Use> at High Speed(480Mbps)
unknown vendor : unknown product (0000:7777)
3-1 -> usbip://localhost:3240/1-6
-> remote bus/dev 001/005
======================== usbip port output end ================================
3. Speaking about the second and the third sleep, we need to put sleep there
because there is no synchronization between kernel and userspace.
Comment it out to observe other behaviour.
Best,
Alexander Timofeev
On Sat, May 27, 2023 at 1:32 AM Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On 5/24/23 11:48, Alexander Timofeev wrote:
> > Hi!
> >
> > Sorry if you have received this email twice. My first email contained
> > html and was not accepted by the mailing list.
> >
> > I think I have found a race condition which can be triggered for
> > example when calling two usbip attach commands in parallel on the same
> > host.
> >
> > In file linux/tools/usb/usbip/src /usbip_attach.c:
> > In function static int import_device(int sockfd, struct usbip_usb_device *udev):
> >
> > At first two processes may call usbip_vhci_driver_open() before
> > entering the do-while loop.
> > Next they both call usbip_vhci_get_free_port() and get the same free port.
> > Finally, they pass the same port number to usbip_vhci_attach_device().
> >
> > Current recommendation to end users: run usbip attach commands only
> > sequentially.
> >
>
> Will you be able to share the reproducer?
>
> thanks,
> -- Shuah
>
