Re: [PATCH 1/1] usbip/userspace/libsrc/names.c: memory leak
On Mon, Jan 27, 2014 at 11:29:48PM +0100, xypron.g...@gmx.de wrote: From: Heinrich Schuchardt xypron.g...@gmx.de p is freed if NULL. Not a real problem, right? p is leaked if second calloc fails. You just created a new bug in your fix :( Please run your patches through scripts/checkpatch.pl, odds are, it would have caught this error. greg k-h -- 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 1/1] usbip/userspace/libsrc/names.c: memory leak
Hello.
On 01/28/2014 01:29 AM, xypron.g...@gmx.de wrote:
From: Heinrich Schuchardt xypron.g...@gmx.de
p is freed if NULL.
This is not an issue.
p is leaked if second calloc fails.
Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de
---
drivers/staging/usbip/userspace/libsrc/names.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/names.c
b/drivers/staging/usbip/userspace/libsrc/names.c
index 3c8d28b..b2904e8 100644
--- a/drivers/staging/usbip/userspace/libsrc/names.c
+++ b/drivers/staging/usbip/userspace/libsrc/names.c
@@ -170,12 +170,12 @@ static void *my_malloc(size_t size)
p = calloc(1, sizeof(struct pool));
if (!p) {
- free(p);
return NULL;
}
{} not needed anymore.
p-mem = calloc(1, size);
if (!p-mem)
+ free(p);
return NULL;
How about {} around the *if* arm?
WBR, Sergei
--
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 1/1] usbip/userspace/libsrc/names.c: memory leak
On Mon, Jan 27, 2014 at 11:29:48PM +0100, xypron.g...@gmx.de wrote:
From: Heinrich Schuchardt xypron.g...@gmx.de
Fix your email account so we can get this automatically from your email.
Currently the From header on your email is just:
From: xypron.g...@gmx.de
without your name.
p is freed if NULL.
p is leaked if second calloc fails.
Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de
---
drivers/staging/usbip/userspace/libsrc/names.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/names.c
b/drivers/staging/usbip/userspace/libsrc/names.c
index 3c8d28b..b2904e8 100644
--- a/drivers/staging/usbip/userspace/libsrc/names.c
+++ b/drivers/staging/usbip/userspace/libsrc/names.c
@@ -170,12 +170,12 @@ static void *my_malloc(size_t size)
p = calloc(1, sizeof(struct pool));
if (!p) {
- free(p);
return NULL;
}
Remove the curly braces from here since they are no longer needed.
p-mem = calloc(1, size);
if (!p-mem)
+ free(p);
return NULL;
Add the curly braces here. They are required.
regards,
dan carpenter
--
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 1/1] usbip/userspace/libsrc/names.c: memory leak
On Mon, Jan 27, 2014 at 02:50:04PM -0800, Greg KH wrote: On Mon, Jan 27, 2014 at 11:29:48PM +0100, xypron.g...@gmx.de wrote: From: Heinrich Schuchardt xypron.g...@gmx.de p is freed if NULL. Not a real problem, right? p is leaked if second calloc fails. You just created a new bug in your fix :( Please run your patches through scripts/checkpatch.pl, odds are, it would have caught this error. Checkpatch doesn't catch the problems here. I thought it would have caught the style issue but apparently it only looks for extra curly braces when you run it in --file mode. Fengguang would hopefully have caught the missing curly braces bug with Coccinelle. regards, dan carpenter -- 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 1/1] usbip/userspace/libsrc/names.c: memory leak
On Tue, Jan 28, 2014 at 02:02:12AM +0300, Dan Carpenter wrote: On Mon, Jan 27, 2014 at 02:50:04PM -0800, Greg KH wrote: On Mon, Jan 27, 2014 at 11:29:48PM +0100, xypron.g...@gmx.de wrote: From: Heinrich Schuchardt xypron.g...@gmx.de p is freed if NULL. Not a real problem, right? p is leaked if second calloc fails. You just created a new bug in your fix :( Please run your patches through scripts/checkpatch.pl, odds are, it would have caught this error. Checkpatch doesn't catch the problems here. I thought it would have caught the style issue but apparently it only looks for extra curly braces when you run it in --file mode. Ah, that's good to know. Fengguang would hopefully have caught the missing curly braces bug with Coccinelle. Is Coccinelle run on the userspace .c code in the kernel? thanks, greg k-h -- 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 1/1] usbip/userspace/libsrc/names.c: memory leak
On Mon, Jan 27, 2014 at 03:27:36PM -0800, Greg KH wrote: On Tue, Jan 28, 2014 at 02:02:12AM +0300, Dan Carpenter wrote: On Mon, Jan 27, 2014 at 02:50:04PM -0800, Greg KH wrote: On Mon, Jan 27, 2014 at 11:29:48PM +0100, xypron.g...@gmx.de wrote: From: Heinrich Schuchardt xypron.g...@gmx.de p is freed if NULL. Not a real problem, right? p is leaked if second calloc fails. You just created a new bug in your fix :( Please run your patches through scripts/checkpatch.pl, odds are, it would have caught this error. Checkpatch doesn't catch the problems here. I thought it would have caught the style issue but apparently it only looks for extra curly braces when you run it in --file mode. Ah, that's good to know. Fengguang would hopefully have caught the missing curly braces bug with Coccinelle. Is Coccinelle run on the userspace .c code in the kernel? Hm... I'm not sure. Fengguang, do you know if we would have caught the missing curly braces in this patch? http://lkml.org/lkml/2014/1/27/460 regards, dan carpenter -- 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
