Message-ID: <475764c3-ac04-4a8b-8301-8f05c781eaf8@rowland.harvard.edu>
Date: Tue, 16 Sep 2025 11:50:47 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Forest Crossman <cyrozap@...il.com>
Cc: gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: mon: Increase BUFF_MAX to 64 MiB to support
 multi-MB URBs

On Mon, Sep 15, 2025 at 03:55:10PM -0400, Forest Crossman wrote:
> The usbmon binary interface currently truncates captures of large
> transfers from higher-speed USB devices. Because a single event capture
> is limited to one-fifth of the total buffer size, the current maximum
> size of a captured URB is around 240 KiB. This is insufficient when
> capturing traffic from modern devices that use transfers of several
> hundred kilobytes or more, as truncated URBs can make it impossible for
> user-space USB analysis tools like Wireshark to properly defragment and
> reassemble higher-level protocol packets in the captured data.
> 
> The root cause of this issue is the 1200 KiB BUFF_MAX limit, which has
> not been changed since the binary interface was introduced in 2006.
> 
> To resolve this issue, this patch increases BUFF_MAX to 64 MiB. The
> original comment for BUFF_MAX based the limit's calculation on a
> saturated 480 Mbit/s bus. Applying the same logic to a modern USB 3.2
> Gen 2×2 20 Gbit/s bus (~2500 MB/s over a 20ms window) indicates the
> buffer should be at least 50 MB. The new limit of 64 MiB covers that,
> plus a little extra for any overhead.
> 
> With this change, both users and developers should now be able to debug
> and reverse engineer modern USB devices even when running unmodified
> distro kernels.
> 
> Please note that this change does not affect the default buffer size. A
> larger buffer is only allocated when a user explicitly requests it via
> the MON_IOCT_RING_SIZE ioctl, so the change to the maximum buffer size
> should not unduly increase memory usage for users that don't
> deliberately request a larger buffer.
> 
> Fixes: 6f23ee1fefdc ("USB: add binary API to usbmon")
> Link: https://lore.kernel.org/CAO3ALPzdUkmMr0YMrODLeDSLZqNCkWcAP8NumuPHLjNJ8wC1kQ@mail.gmail.com
> Signed-off-by: Forest Crossman <cyrozap@...il.com>
> ---

Acked-by: Alan Stern <stern@...land.harvard.edu>

>  drivers/usb/mon/mon_bin.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/mon/mon_bin.c b/drivers/usb/mon/mon_bin.c
> index c93b43f5bc46..e713fc5964b1 100644
> --- a/drivers/usb/mon/mon_bin.c
> +++ b/drivers/usb/mon/mon_bin.c
> @@ -68,18 +68,20 @@
>   * The magic limit was calculated so that it allows the monitoring
>   * application to pick data once in two ticks. This way, another application,
>   * which presumably drives the bus, gets to hog CPU, yet we collect our data.
> - * If HZ is 100, a 480 mbit/s bus drives 614 KB every jiffy. USB has an
> - * enormous overhead built into the bus protocol, so we need about 1000 KB.
> + *
> + * Originally, for a 480 Mbit/s bus this required a buffer of about 1 MB. For
> + * modern 20 Gbps buses, this value increases to over 50 MB. The maximum
> + * buffer size is set to 64 MiB to accommodate this.
>   *
>   * This is still too much for most cases, where we just snoop a few
>   * descriptor fetches for enumeration. So, the default is a "reasonable"
> - * amount for systems with HZ=250 and incomplete bus saturation.
> + * amount for typical, low-throughput use cases.
>   *
>   * XXX What about multi-megabyte URBs which take minutes to transfer?
>   */
> -#define BUFF_MAX  CHUNK_ALIGN(1200*1024)
> -#define BUFF_DFL   CHUNK_ALIGN(300*1024)
> -#define BUFF_MIN     CHUNK_ALIGN(8*1024)
> +#define BUFF_MAX  CHUNK_ALIGN(64*1024*1024)
> +#define BUFF_DFL      CHUNK_ALIGN(300*1024)
> +#define BUFF_MIN        CHUNK_ALIGN(8*1024)
> 
>  /*
>   * The per-event API header (2 per URB).
> -- 
> 2.50.1
> 

Powered by blists - more mailing lists