[PATCH v2] usb: Remove stack VLA usage

2018-03-08 Thread Tobin C. Harding
The kernel would like to have all stack VLA usage removed[1].  We
already have a pre-processor constant defined MAX_SGLEN.  We can use
this instead of the variable param-sglen.

[1]: https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Tobin C. Harding <m...@tobin.cc>
---
 drivers/usb/misc/usbtest.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 90028ef541e3..9e1142b8b91b 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -2028,11 +2028,14 @@ test_queue(struct usbtest_dev *dev, struct 
usbtest_param_32 *param,
unsignedi;
unsigned long   packets = 0;
int status = 0;
-   struct urb  *urbs[param->sglen];
+   struct urb  *urbs[MAX_SGLEN];
 
if (!param->sglen || param->iterations > UINT_MAX / param->sglen)
return -EINVAL;
 
+   if (param->sglen > MAX_SGLEN)
+   return -EINVAL;
+
memset(, 0, sizeof(context));
context.count = param->iterations * param->sglen;
context.dev = dev;
-- 
2.7.4

--
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


Re: [PATCH 3/4] usb: Remove stack VLA usage

2018-03-08 Thread Tobin C. Harding
On Fri, Mar 09, 2018 at 04:55:35PM +1100, Tobin C. Harding wrote:
> Signed-off-by: Tobin C. Harding <m...@tobin.cc>
> ---

Please drop this.  To much on github not writing proper commit logs :(

v2 to come.

thanks,
Tobin.
--
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


[PATCH 3/4] usb: Remove stack VLA usage

2018-03-08 Thread Tobin C. Harding
Signed-off-by: Tobin C. Harding <m...@tobin.cc>
---
 drivers/usb/misc/usbtest.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 90028ef541e3..9e1142b8b91b 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -2028,11 +2028,14 @@ test_queue(struct usbtest_dev *dev, struct 
usbtest_param_32 *param,
unsignedi;
unsigned long   packets = 0;
int status = 0;
-   struct urb  *urbs[param->sglen];
+   struct urb  *urbs[MAX_SGLEN];
 
if (!param->sglen || param->iterations > UINT_MAX / param->sglen)
return -EINVAL;
 
+   if (param->sglen > MAX_SGLEN)
+   return -EINVAL;
+
memset(, 0, sizeof(context));
context.count = param->iterations * param->sglen;
context.dev = dev;
-- 
2.7.4

--
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


Re: [PATCH 00/18] use ARRAY_SIZE macro

2017-10-01 Thread Tobin C. Harding
On Sun, Oct 01, 2017 at 03:30:38PM -0400, Jérémy Lefaure wrote:
> Hi everyone,
> Using ARRAY_SIZE improves the code readability. I used coccinelle (I
> made a change to the array_size.cocci file [1]) to find several places
> where ARRAY_SIZE could be used instead of other macros or sizeof
> division.
> 
> I tried to divide the changes into a patch per subsystem (excepted for
> staging). If one of the patch should be split into several patches, let
> me know.
> 
> In order to reduce the size of the To: and Cc: lines, each patch of the
> series is sent only to the maintainers and lists concerned by the patch.
> This cover letter is sent to every list concerned by this series.

Why don't you just send individual patches for each subsystem? I'm not a 
maintainer but I don't see
how any one person is going to be able to apply this whole series, it is making 
it hard for
maintainers if they have to pick patches out from among the series (if indeed 
any will bother
doing that).

I get that this will be more work for you but AFAIK we are optimizing for 
maintainers.

Good luck,
Tobin.
--
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