Re: [PATCH] usbip: vhci_hcd: store seqnums as u32 to fix lost unlinks after 2^31

[Lucas Pascal <lucas.pascal@pqshield.com>]

Hi Shuah,

Sorry for the duplicates: my earlier replies went to you only, or were
sent with HTML bits by Gmail and rejected by the list. This is a
(hopefully right) plain-text resend to everyone.

On Mon, 19 Oct 2026 at 21:06, Shuah Khan <skhan@linuxfoundation.org> wrote:
> Can you reproduce this with usbip_host and client exchanging messages?

The QEMU test I mentioned may cover that already. It goes as follows:
- dummy_hcd is activated and g_zero is "plugged into" it.
- Host side: usbipd + "usbip bind" hand the device to usbip_host.
- Client side: "usbip attach -r 127.0.0.1" imports it through
  vhci_hcd.
- Transport: the real usbip_host <-> vhci_hcd protocol over TCP
  (loopback), no simulated peer. Same setup as the production machine
  where I hit the bug.
- Traffic test itself: I reused the usbtest test case 11 (unlink reads)
  with 3000 iterations:
  /opt/testusb -D /dev/bus/usb/<M>/<N> -t 11 -s 512 -c 3000
- As I modified vhci_hcd->seqnum at INT_MAX - 2000, the test crosses
  2^31 within seconds.

From there I can think of other tests:
- using another test case which does not focus on unlinks (case 1, 2?),
- host and client on different machines.

Would either be helpful?

> have you noticed "seqnum max" messages in dmesg while you were running
> tests?

Not in the QEMU before/after test itself. seqnum starts at
INT_MAX - 2000, above 0xffff, so given the driver code it won't trigger
the message:

  if (priv->seqnum == 0xffff)
      dev_info(&urb->dev->dev, "seqnum max\n");

However I did see it on the production runner server, ~20m after it
booted. The counter then kept going until it crossed 2^31 a month later:

2026-09-15T16:01:36+01:00 fwtest35 kernel: Linux version 7.0.0-31-generic (buildd@lcy02-amd64-060) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #31~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Aug 10 09:38:02 UTC 2 (Ubuntu 7.0.0-31.31~24.04.1-generic 7.0.14)
[...]
2026-09-15T16:24:45+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 37862
2026-09-15T16:24:45+01:00 fwtest35 kernel: vhci_hcd: urb->status -104
2026-09-15T16:24:45+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 37865
2026-09-15T16:24:45+01:00 fwtest35 kernel: vhci_hcd: urb->status -104
2026-09-15T16:24:45+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 37867
2026-09-15T16:24:45+01:00 fwtest35 kernel: vhci_hcd: urb->status -104
2026-09-15T16:24:48+01:00 fwtest35 kernel: usb 5-5: seqnum max
2026-09-15T16:24:49+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 75555
2026-09-15T16:24:49+01:00 fwtest35 kernel: vhci_hcd: urb->status -104
2026-09-15T16:24:49+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 75556
2026-09-15T16:24:49+01:00 fwtest35 kernel: vhci_hcd: urb->status -104
2026-09-15T16:24:49+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 75557
[...]
2026-10-15T17:31:35+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 2147467545
2026-10-15T17:31:35+01:00 fwtest35 kernel: vhci_hcd: urb->status -104
2026-10-15T17:31:35+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 2147467547
2026-10-15T17:31:35+01:00 fwtest35 kernel: vhci_hcd: urb->status -104
2026-10-15T17:31:35+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 2147467551
2026-10-15T17:31:35+01:00 fwtest35 kernel: vhci_hcd: urb->status -104
2026-10-15T17:31:39+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 18446744071562096407
2026-10-15T17:31:39+01:00 fwtest35 kernel: vhci_hcd: cannot find the pending unlink 2147512087
2026-10-15T17:31:39+01:00 fwtest35 kernel: vhci_hcd: unlink->seqnum 18446744071562096629
2026-10-15T17:31:39+01:00 fwtest35 kernel: vhci_hcd: cannot find the pending unlink 2147512309

These last numbers show the bug:
- 2147467551 = 0x7fffc11f, < 0x80000000 - the bug doesn't trigger before
  2^31,
- 18446744071562096629 = 0xffffffff80006ff5 - the bug triggers,
  seqnum > 2^31 are sign-extended with 0xffffffff,
- 2147512309 = 0x80006ff5 - the expected seqnum.

Thank you,
Lucas