Re: [RFC] usb: mon: Increase BUFF_MAX to support modern higher-speed devices

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Sep 08, 2025 at 11:50:00PM -0500, Forest Crossman wrote:
> Hello,
> 
> The usbmon binary interface currently truncates captures for large
> transfers from higher-speed USB devices. This is caused by the
> BUFF_MAX limit in drivers/usb/mon/mon_bin.c, which has not been
> updated since the usbmon binary interface was first introduced in
> 2006. A single event capture is limited to one-fifth of the total
> buffer size, capping URB captures at 240 KiB each.
> 
> I discovered this limitation while developing a Wireshark protocol
> dissector [1], where truncated captures made it impossible for the
> dissector to defragment and reassemble the protocol packets (an
> example of this truncation can be seen in frame 1580 of this capture
> file [2]). Others in the community have also encountered this hard
> limit when working with modern devices that use transfers of several
> hundred kilobytes or more [3].
> 
> The original comment for BUFF_MAX based its calculation on a saturated
> 480 Mbit/s bus. Applying the same logic to a USB 3.2 Gen 2×2 20 Gbit/s
> bus (~2500 MB/s over a 20ms window) indicates a required buffer size
> of at least 50 MB.
> 
> I propose increasing BUFF_MAX to 64 MiB. Making this change would
> enable usbmon to better support capturing the USB traffic of modern
> higher-speed devices, enabling users and developers to debug and
> reverse engineer their USB devices while running unmodified distro
> kernels. This change would not affect the default buffer size, as a
> larger buffer is only allocated when explicitly requested via the
> MON_IOCT_RING_SIZE ioctl.
> 
> This proposal follows the same rationale as the original calculation,
> but with updates for modern hardware.
> 
> I would appreciate any feedback on this approach before I prepare a patch.

I would suggest trying it out and seeing if it will work properly.  CPU
speeds are faster now, so a larger buffer will probably be just fine,
but I think the original goal here was that the majority of the "real"
information was in the beginning of the urb (protocol stuff, not
data), so the end of the urb wasn't all that necessary to see if the
buffer was too big.  And, as you point out, 480 Mbit was the speeds
then, we didn't think that USB would ever be boosted to go this fast :)

thanks,

greg k-h