On Fri, 9 Dec 2016, Mateusz Berezecki wrote:
> Promote a variable keeping track of USB transfer memory usage to a
> wider data type and allow for higher bandwidth transfers from a large
> number of USB devices connected to a single host.
>
> Signed-off-by: Mateusz Berezecki <mateuszb@xxxxxxxxxxx>
> ---
> drivers/usb/core/devio.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 4016dae..f13b401 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -134,20 +134,20 @@ enum snoop_when {
> #define USB_DEVICE_DEV MKDEV(USB_DEVICE_MAJOR, 0)
>
> /* Limit on the total amount of memory we can allocate for transfers */
> -static unsigned usbfs_memory_mb = 16;
> +static u32 usbfs_memory_mb = 16;
> module_param(usbfs_memory_mb, uint, 0644);
> MODULE_PARM_DESC(usbfs_memory_mb,
> "maximum MB allowed for usbfs buffers (0 = no limit)");
>
> -/* Hard limit, necessary to avoid arithmetic overflow */
> -#define USBFS_XFER_MAX (UINT_MAX / 2 - 1000000)
> +/* Hard limit */
> +#define USBFS_XFER_MAX (1ull << 52)
I should have realized this before -- my fault. Since usbfs_memory_mb
is a u32 value, it can never be >= 2^32 MB. Consequently, the total
memory limit can never be >= 2^52 bytes, so there's no need for
USBFS_XFER_MAX at all!
The only reason it's there now is, like the comment says, with 32-bit
values the user could cause an arithmetic overflow. With 64-bit values
that isn't possible.
So you might as well just get rid of it entirely.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
