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 <mateu...@fastmail.fm> > --- > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html