fixes for ioctl() of usbtmc in testing tree

Zitat von Greg Kroah-Hartman <[email protected]>:

Quoted 46 lines · On Mon, Sep 24, 2018 at 12:20:42PM +0000, [email protected] wrote:

Quoted 45 lines

Zitat von Oliver Neukum <[email protected]>:

Quoted 10 lines · On Mo, 2018-09-24 at 10:56 +0000, [email protected] wrote:

Quoted 9 lines

Zitat von Greg Kroah-Hartman <[email protected]>:

Quoted 7 lines · Oliver Neukum

Quoted 4 lines

Hi,

how should I mark fixes intended for the testing branch? I got one for the usbtmc driver.

Just send it like normal. You can do a "Fixes:" tag with the

sha1, that

Quoted 10 lines

Quoted 6 lines

Quoted 3 lines

should be fine. I need to push out my testing branch now, 0-day seems to be stalled :(

Big sorry! There is a superflous kmalloc line 1270 til 1272. Shall I send the fix?

Damn. That is the same allocation repeated, not a reuse of the buffer. I'll resend. There is also a leak in the error case.

I do not see a leak in the error case. kfree(NULL) should be ok. Sorry, I referred the line 1270 to the mail of Dan Carpenter. I mean the lines:

drivers/usb/class/usbtmc.c +0 -4

index 0fcb81a1399b..dfbcf418dad7 100644
@@ -1895,10 +1895,6 @@ static int usbtmc_ioctl_request(struct
 usbtmc_device_data *data,
        if (res)
                return -EFAULT;
 
-       buffer = kmalloc(request.req.wLength, GFP_KERNEL);
-       if (!buffer)
-               return -ENOMEM;
-
        if (request.req.wLength > USBTMC_BUFSIZE)
                return -EMSGSIZE;

Quoted 6 lines

Quoted 3 lines

@Oliver: Where do send (resend) the fix? Is this an official fix or do you just fix your internal build system?
And I still have to make an official fix, isn't it?

Yes, you need to send a "real" patch for anyone to be able to pick it up.

I sent the patch series: https://patchwork.kernel.org/cover/10612963/
Anything else I can do to relieve my bad conscience?