[PATCH] btrfs: fix memory leakage
The memory allocated to "name" by function "extref_get_fields" isn't properly
freed when error occurs.
Signed-off-by: Cong Ding
---
fs/btrfs/tree-log.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 79f057c..e75f3ed 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1169,8 +1169,10 @@ static noinline int add_inode_ref(struct
btrfs_trans_handle *trans,
*/
if (!dir)
dir = read_one_inode(root, parent_objectid);
- if (!dir)
+ if (!dir) {
+ kfree(name);
return -ENOENT;
+ }
} else {
ret = ref_get_fields(eb, ref_ptr, , ,
_index);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] btrfs: fix memory leakage
The memory allocated to name by function extref_get_fields isn't properly
freed when error occurs.
Signed-off-by: Cong Ding ding...@gmail.com
---
fs/btrfs/tree-log.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 79f057c..e75f3ed 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1169,8 +1169,10 @@ static noinline int add_inode_ref(struct
btrfs_trans_handle *trans,
*/
if (!dir)
dir = read_one_inode(root, parent_objectid);
- if (!dir)
+ if (!dir) {
+ kfree(name);
return -ENOENT;
+ }
} else {
ret = ref_get_fields(eb, ref_ptr, namelen, name,
ref_index);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs/9p: fix flags in the format of printf
To print "int" value, we should use %d rather than %u.
Signed-off-by: Cong Ding
---
fs/9p/vfs_inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index af7d531..dcc099a 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -147,7 +147,7 @@ static umode_t p9mode2unixmode(struct v9fs_session_info
*v9ses,
int major = -1, minor = -1;
strlcpy(ext, stat->extension, sizeof(ext));
- sscanf(ext, "%c %u %u", , , );
+ sscanf(ext, "%c %d %d", , , );
switch (type) {
case 'c':
res |= S_IFCHR;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs/9p: fix flags in the format of printf
To print int value, we should use %d rather than %u.
Signed-off-by: Cong Ding ding...@gmail.com
---
fs/9p/vfs_inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index af7d531..dcc099a 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -147,7 +147,7 @@ static umode_t p9mode2unixmode(struct v9fs_session_info
*v9ses,
int major = -1, minor = -1;
strlcpy(ext, stat-extension, sizeof(ext));
- sscanf(ext, %c %u %u, type, major, minor);
+ sscanf(ext, %c %d %d, type, major, minor);
switch (type) {
case 'c':
res |= S_IFCHR;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] uio: fix memory leak
we have to call kobject_put() to clean up the kobject after function
kobject_init(), kobject_add(), or kobject_uevent() is called.
Signed-off-by: Cong Ding
---
drivers/uio/uio.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 11d4e0a..539d148 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -288,13 +288,13 @@ static int uio_dev_add_attributes(struct uio_device *idev)
}
map = kzalloc(sizeof(*map), GFP_KERNEL);
if (!map)
- goto err_map;
+ goto err_map_kobj;
kobject_init(>kobj, _attr_type);
map->mem = mem;
mem->map = map;
ret = kobject_add(>kobj, idev->map_dir, "map%d", mi);
if (ret)
- goto err_map;
+ goto err_map_kobj;
ret = kobject_uevent(>kobj, KOBJ_ADD);
if (ret)
goto err_map;
@@ -313,14 +313,14 @@ static int uio_dev_add_attributes(struct uio_device *idev)
}
portio = kzalloc(sizeof(*portio), GFP_KERNEL);
if (!portio)
- goto err_portio;
+ goto err_portio_kobj;
kobject_init(>kobj, _attr_type);
portio->port = port;
port->portio = portio;
ret = kobject_add(>kobj, idev->portio_dir,
"port%d", pi);
if (ret)
- goto err_portio;
+ goto err_portio_kobj;
ret = kobject_uevent(>kobj, KOBJ_ADD);
if (ret)
goto err_portio;
@@ -329,14 +329,18 @@ static int uio_dev_add_attributes(struct uio_device *idev)
return 0;
err_portio:
- for (pi--; pi >= 0; pi--) {
+ pi--;
+err_portio_kobj:
+ for (; pi >= 0; pi--) {
port = >info->port[pi];
portio = port->portio;
kobject_put(>kobj);
}
kobject_put(idev->portio_dir);
err_map:
- for (mi--; mi>=0; mi--) {
+ mi--;
+err_map_kobj:
+ for (; mi >= 0; mi--) {
mem = >info->mem[mi];
map = mem->map;
kobject_put(>kobj);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] uio: fix memory leak
we have to call kobject_put() to clean up the kobject after function
kobject_init(), kobject_add(), or kobject_uevent() is called.
Signed-off-by: Cong Ding ding...@gmail.com
---
drivers/uio/uio.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 11d4e0a..539d148 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -288,13 +288,13 @@ static int uio_dev_add_attributes(struct uio_device *idev)
}
map = kzalloc(sizeof(*map), GFP_KERNEL);
if (!map)
- goto err_map;
+ goto err_map_kobj;
kobject_init(map-kobj, map_attr_type);
map-mem = mem;
mem-map = map;
ret = kobject_add(map-kobj, idev-map_dir, map%d, mi);
if (ret)
- goto err_map;
+ goto err_map_kobj;
ret = kobject_uevent(map-kobj, KOBJ_ADD);
if (ret)
goto err_map;
@@ -313,14 +313,14 @@ static int uio_dev_add_attributes(struct uio_device *idev)
}
portio = kzalloc(sizeof(*portio), GFP_KERNEL);
if (!portio)
- goto err_portio;
+ goto err_portio_kobj;
kobject_init(portio-kobj, portio_attr_type);
portio-port = port;
port-portio = portio;
ret = kobject_add(portio-kobj, idev-portio_dir,
port%d, pi);
if (ret)
- goto err_portio;
+ goto err_portio_kobj;
ret = kobject_uevent(portio-kobj, KOBJ_ADD);
if (ret)
goto err_portio;
@@ -329,14 +329,18 @@ static int uio_dev_add_attributes(struct uio_device *idev)
return 0;
err_portio:
- for (pi--; pi = 0; pi--) {
+ pi--;
+err_portio_kobj:
+ for (; pi = 0; pi--) {
port = idev-info-port[pi];
portio = port-portio;
kobject_put(portio-kobj);
}
kobject_put(idev-portio_dir);
err_map:
- for (mi--; mi=0; mi--) {
+ mi--;
+err_map_kobj:
+ for (; mi = 0; mi--) {
mem = idev-info-mem[mi];
map = mem-map;
kobject_put(map-kobj);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] avr32: boards/atngw100/mrmt.c: fix building error
there is an additional "{", which causes building error.
Signed-off-by: Cong Ding
---
arch/avr32/boards/atngw100/mrmt.c |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/avr32/boards/atngw100/mrmt.c
b/arch/avr32/boards/atngw100/mrmt.c
index ccc9599..1ba09e4 100644
--- a/arch/avr32/boards/atngw100/mrmt.c
+++ b/arch/avr32/boards/atngw100/mrmt.c
@@ -150,7 +150,6 @@ static struct ac97c_platform_data __initdata ac97c0_data = {
static struct platform_device rmt_ts_device = {
.name = "ucb1400_ts",
.id = -1,
- }
};
#endif
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] avr32: boards/atngw100/mrmt.c: fix building error
there is an additional {, which causes building error.
Signed-off-by: Cong Ding ding...@gmail.com
---
arch/avr32/boards/atngw100/mrmt.c |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/avr32/boards/atngw100/mrmt.c
b/arch/avr32/boards/atngw100/mrmt.c
index ccc9599..1ba09e4 100644
--- a/arch/avr32/boards/atngw100/mrmt.c
+++ b/arch/avr32/boards/atngw100/mrmt.c
@@ -150,7 +150,6 @@ static struct ac97c_platform_data __initdata ac97c0_data = {
static struct platform_device rmt_ts_device = {
.name = ucb1400_ts,
.id = -1,
- }
};
#endif
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Mon, May 27, 2013 at 12:14 AM, Cong Ding wrote: > On Thu, Apr 25, 2013 at 12:19 PM, Cong Ding wrote: >> On Thu, Feb 14, 2013 at 12:43:15PM +0100, Cong Ding wrote: >>> On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: >>> > On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: >>> > > On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: >>> > > > On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch >>> > > > wrote: >>> > > > > On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: >>> > > > >> In version 1, I forgot to modify the same bug in the first loop. >>> > > > >> >>> > > > >> we have to call kobject_put() to clean up the kobject after >>> > > > >> function >>> > > > >> kobject_init(), kobject_add(), or kobject_uevent() is called. >>> > > > >> >>> > > > >> Signed-off-by: Cong Ding >>> > > > > >>> > > > > Signed-off-by: "Hans J. Koch" >>> > > > >>> > > > Hi Greg, is this patch stil in the queue? >>> > > >>> > > Hans is queueing up UIO patches to send to me, I'm waiting for him to >>> > > send them as I don't have any in my trees. >>> > >>> > I'll set that up tonight or tomorrow. Sorry, I was delayed by illness >>> > and a lot of other work. >>> Hi Hans, what's this going on? >>> >>> Thanks, - cong > Hi Hans, it's another month. What's the progress of this patch? still no action to this this patch? it was signed-off by Hans 7 months ago! - cong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Mon, May 27, 2013 at 12:14 AM, Cong Ding ding...@gmail.com wrote: On Thu, Apr 25, 2013 at 12:19 PM, Cong Ding ding...@gmail.com wrote: On Thu, Feb 14, 2013 at 12:43:15PM +0100, Cong Ding wrote: On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch h...@hansjkoch.de wrote: On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: In version 1, I forgot to modify the same bug in the first loop. we have to call kobject_put() to clean up the kobject after function kobject_init(), kobject_add(), or kobject_uevent() is called. Signed-off-by: Cong Ding ding...@gmail.com Signed-off-by: Hans J. Koch h...@hansjkoch.de Hi Greg, is this patch stil in the queue? Hans is queueing up UIO patches to send to me, I'm waiting for him to send them as I don't have any in my trees. I'll set that up tonight or tomorrow. Sorry, I was delayed by illness and a lot of other work. Hi Hans, what's this going on? Thanks, - cong Hi Hans, it's another month. What's the progress of this patch? still no action to this this patch? it was signed-off by Hans 7 months ago! - cong -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Thu, Apr 25, 2013 at 12:19 PM, Cong Ding wrote: > On Thu, Feb 14, 2013 at 12:43:15PM +0100, Cong Ding wrote: >> On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: >> > On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: >> > > On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: >> > > > On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch >> > > > wrote: >> > > > > On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: >> > > > >> In version 1, I forgot to modify the same bug in the first loop. >> > > > >> >> > > > >> we have to call kobject_put() to clean up the kobject after function >> > > > >> kobject_init(), kobject_add(), or kobject_uevent() is called. >> > > > >> >> > > > >> Signed-off-by: Cong Ding >> > > > > >> > > > > Signed-off-by: "Hans J. Koch" >> > > > >> > > > Hi Greg, is this patch stil in the queue? >> > > >> > > Hans is queueing up UIO patches to send to me, I'm waiting for him to >> > > send them as I don't have any in my trees. >> > >> > I'll set that up tonight or tomorrow. Sorry, I was delayed by illness >> > and a lot of other work. >> Hi Hans, what's this going on? >> >> Thanks, - cong Hi Hans, it's another month. What's the progress of this patch? - cong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Thu, Apr 25, 2013 at 12:19 PM, Cong Ding ding...@gmail.com wrote: On Thu, Feb 14, 2013 at 12:43:15PM +0100, Cong Ding wrote: On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch h...@hansjkoch.de wrote: On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: In version 1, I forgot to modify the same bug in the first loop. we have to call kobject_put() to clean up the kobject after function kobject_init(), kobject_add(), or kobject_uevent() is called. Signed-off-by: Cong Ding ding...@gmail.com Signed-off-by: Hans J. Koch h...@hansjkoch.de Hi Greg, is this patch stil in the queue? Hans is queueing up UIO patches to send to me, I'm waiting for him to send them as I don't have any in my trees. I'll set that up tonight or tomorrow. Sorry, I was delayed by illness and a lot of other work. Hi Hans, what's this going on? Thanks, - cong Hi Hans, it's another month. What's the progress of this patch? - cong -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Thu, Feb 14, 2013 at 12:43:15PM +0100, Cong Ding wrote: > On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: > > On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: > > > On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: > > > > On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch wrote: > > > > > On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: > > > > >> In version 1, I forgot to modify the same bug in the first loop. > > > > >> > > > > >> we have to call kobject_put() to clean up the kobject after function > > > > >> kobject_init(), kobject_add(), or kobject_uevent() is called. > > > > >> > > > > >> Signed-off-by: Cong Ding > > > > > > > > > > Signed-off-by: "Hans J. Koch" > > > > > > > > Hi Greg, is this patch stil in the queue? > > > > > > Hans is queueing up UIO patches to send to me, I'm waiting for him to > > > send them as I don't have any in my trees. > > > > I'll set that up tonight or tomorrow. Sorry, I was delayed by illness > > and a lot of other work. > Hi Hans, what's this going on? > > Thanks, - cong ping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Thu, Feb 14, 2013 at 12:43:15PM +0100, Cong Ding wrote: On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch h...@hansjkoch.de wrote: On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: In version 1, I forgot to modify the same bug in the first loop. we have to call kobject_put() to clean up the kobject after function kobject_init(), kobject_add(), or kobject_uevent() is called. Signed-off-by: Cong Ding ding...@gmail.com Signed-off-by: Hans J. Koch h...@hansjkoch.de Hi Greg, is this patch stil in the queue? Hans is queueing up UIO patches to send to me, I'm waiting for him to send them as I don't have any in my trees. I'll set that up tonight or tomorrow. Sorry, I was delayed by illness and a lot of other work. Hi Hans, what's this going on? Thanks, - cong ping -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: > On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: > > On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: > > > On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch wrote: > > > > On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: > > > >> In version 1, I forgot to modify the same bug in the first loop. > > > >> > > > >> we have to call kobject_put() to clean up the kobject after function > > > >> kobject_init(), kobject_add(), or kobject_uevent() is called. > > > >> > > > >> Signed-off-by: Cong Ding > > > > > > > > Signed-off-by: "Hans J. Koch" > > > > > > Hi Greg, is this patch stil in the queue? > > > > Hans is queueing up UIO patches to send to me, I'm waiting for him to > > send them as I don't have any in my trees. > > I'll set that up tonight or tomorrow. Sorry, I was delayed by illness > and a lot of other work. Hi Hans, what's this going on? Thanks, - cong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
If it goes to eclk through line 1107, the variable res would be NULL. It will
cause a null pointer dereference error if we call release_mem_region. The
correct way should be using devm_kzalloc rather than kzalloc to allocate
memory.
Signed-off-by: Cong Ding
---
drivers/i2c/busses/i2c-pxa.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..dd2d640 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1094,29 +1094,23 @@ static int i2c_pxa_probe(struct platform_device *dev)
struct resource *res = NULL;
int ret, irq;
- i2c = kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
- if (!i2c) {
- ret = -ENOMEM;
- goto emalloc;
- }
+ i2c = devm_kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
+ if (!i2c)
+ return -ENOMEM;
ret = i2c_pxa_probe_dt(dev, i2c, _type);
if (ret > 0)
ret = i2c_pxa_probe_pdata(dev, i2c, _type);
if (ret < 0)
- goto eclk;
+ return ret;
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
irq = platform_get_irq(dev, 0);
- if (res == NULL || irq < 0) {
- ret = -ENODEV;
- goto eclk;
- }
+ if (res == NULL || irq < 0)
+ return -ENODEV;
- if (!request_mem_region(res->start, resource_size(res), res->name)) {
- ret = -ENOMEM;
- goto eclk;
- }
+ if (!request_mem_region(res->start, resource_size(res), res->name))
+ return -ENOMEM;
i2c->adap.owner = THIS_MODULE;
i2c->adap.retries = 5;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] dma: of-dma.c: fix memory leakage
The memory allocated to ofdma might be a leakage when error occurs.
Signed-off-by: Cong Ding
---
drivers/dma/of-dma.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 59631b2..583e50e3 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -107,6 +107,7 @@ int of_dma_controller_register(struct device_node *np,
if (!nbcells) {
pr_err("%s: #dma-cells property is missing or invalid\n",
__func__);
+ kfree(ofdma);
return -EINVAL;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] dma: of-dma.c: fix memory leakage
The memory allocated to ofdma might be a leakage when error occurs.
Signed-off-by: Cong Ding ding...@gmail.com
---
drivers/dma/of-dma.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 59631b2..583e50e3 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -107,6 +107,7 @@ int of_dma_controller_register(struct device_node *np,
if (!nbcells) {
pr_err(%s: #dma-cells property is missing or invalid\n,
__func__);
+ kfree(ofdma);
return -EINVAL;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
If it goes to eclk through line 1107, the variable res would be NULL. It will
cause a null pointer dereference error if we call release_mem_region. The
correct way should be using devm_kzalloc rather than kzalloc to allocate
memory.
Signed-off-by: Cong Ding ding...@gmail.com
---
drivers/i2c/busses/i2c-pxa.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..dd2d640 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1094,29 +1094,23 @@ static int i2c_pxa_probe(struct platform_device *dev)
struct resource *res = NULL;
int ret, irq;
- i2c = kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
- if (!i2c) {
- ret = -ENOMEM;
- goto emalloc;
- }
+ i2c = devm_kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
+ if (!i2c)
+ return -ENOMEM;
ret = i2c_pxa_probe_dt(dev, i2c, i2c_type);
if (ret 0)
ret = i2c_pxa_probe_pdata(dev, i2c, i2c_type);
if (ret 0)
- goto eclk;
+ return ret;
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
irq = platform_get_irq(dev, 0);
- if (res == NULL || irq 0) {
- ret = -ENODEV;
- goto eclk;
- }
+ if (res == NULL || irq 0)
+ return -ENODEV;
- if (!request_mem_region(res-start, resource_size(res), res-name)) {
- ret = -ENOMEM;
- goto eclk;
- }
+ if (!request_mem_region(res-start, resource_size(res), res-name))
+ return -ENOMEM;
i2c-adap.owner = THIS_MODULE;
i2c-adap.retries = 5;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Sun, Jan 20, 2013 at 10:01:41PM +0100, Hans J. Koch wrote: On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote: On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote: On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch h...@hansjkoch.de wrote: On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote: In version 1, I forgot to modify the same bug in the first loop. we have to call kobject_put() to clean up the kobject after function kobject_init(), kobject_add(), or kobject_uevent() is called. Signed-off-by: Cong Ding ding...@gmail.com Signed-off-by: Hans J. Koch h...@hansjkoch.de Hi Greg, is this patch stil in the queue? Hans is queueing up UIO patches to send to me, I'm waiting for him to send them as I don't have any in my trees. I'll set that up tonight or tomorrow. Sorry, I was delayed by illness and a lot of other work. Hi Hans, what's this going on? Thanks, - cong -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: dma.c: fix memory leakage
On Tue, Feb 12, 2013 at 09:40:25AM -0800, Vinod Koul wrote: > On Tue, Jan 22, 2013 at 10:10:53AM +0000, Cong Ding wrote: > > On Sun, Jan 20, 2013 at 04:24:49PM -0600, Rob Herring wrote: > > > On 01/19/2013 07:06 AM, Cong Ding wrote: > > > > The memory allocated to ofdma might be a leakage when error occurs. > > > > > > > > Signed-off-by: Cong Ding > > > > > > You need to send this to whomever is working on DMA bindings. > > Thank you bob, I added Vinod the the receiver list. > I have moved the of/dma.c to dma/of-dma.c, can you regenerate this patch and > resend to me Sorry Vinod, I didn't manage to get this commit from either linux-next tree or slave-dma tree, and the last commit by you for of/dma.c file is on Jan 7. Did you have any hints for me to get the latest version dma/of-dma.c? - cong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: dma.c: fix memory leakage
On Tue, Feb 12, 2013 at 09:40:25AM -0800, Vinod Koul wrote: On Tue, Jan 22, 2013 at 10:10:53AM +, Cong Ding wrote: On Sun, Jan 20, 2013 at 04:24:49PM -0600, Rob Herring wrote: On 01/19/2013 07:06 AM, Cong Ding wrote: The memory allocated to ofdma might be a leakage when error occurs. Signed-off-by: Cong Ding ding...@gmail.com You need to send this to whomever is working on DMA bindings. Thank you bob, I added Vinod the the receiver list. I have moved the of/dma.c to dma/of-dma.c, can you regenerate this patch and resend to me Sorry Vinod, I didn't manage to get this commit from either linux-next tree or slave-dma tree, and the last commit by you for of/dma.c file is on Jan 7. Did you have any hints for me to get the latest version dma/of-dma.c? - cong -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: mac80211/cfg.c: fix error using of sizeof()
Using 'sizeof' on array given as function argument returns size of a pointer
rather than the size of array.
Signed-off-by: Cong Ding
---
net/mac80211/cfg.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 661b878..af561d5 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2058,7 +2058,8 @@ static int ieee80211_set_mcast_rate(struct wiphy *wiphy,
struct net_device *dev,
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- memcpy(sdata->vif.bss_conf.mcast_rate, rate, sizeof(rate));
+ memcpy(sdata->vif.bss_conf.mcast_rate, rate,
+ sizeof(int) * IEEE80211_NUM_BANDS);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: mac80211/cfg.c: fix error using of sizeof()
Using 'sizeof' on array given as function argument returns size of a pointer
rather than the size of array.
Signed-off-by: Cong Ding ding...@gmail.com
---
net/mac80211/cfg.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 661b878..af561d5 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2058,7 +2058,8 @@ static int ieee80211_set_mcast_rate(struct wiphy *wiphy,
struct net_device *dev,
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- memcpy(sdata-vif.bss_conf.mcast_rate, rate, sizeof(rate));
+ memcpy(sdata-vif.bss_conf.mcast_rate, rate,
+ sizeof(int) * IEEE80211_NUM_BANDS);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
On Tue, Feb 05, 2013 at 09:14:08AM +0800, Haojian Zhuang wrote:
> On Tue, Feb 5, 2013 at 8:05 AM, Cong Ding wrote:
> > If it goes to eclk through line 1107, the variable res would be NULL. It
> > will
> > cause a null pointer dereference error if we call release_mem_region.
> >
> > Signed-off-by: Cong Ding
> > ---
> > drivers/i2c/busses/i2c-pxa.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> > index 1034d93..00df535 100644
> > --- a/drivers/i2c/busses/i2c-pxa.c
> > +++ b/drivers/i2c/busses/i2c-pxa.c
> > @@ -1211,7 +1211,8 @@ eremap:
> > eclk:
> > kfree(i2c);
> > emalloc:
> > - release_mem_region(res->start, resource_size(res));
> > + if (res)
> > + release_mem_region(res->start, resource_size(res));
> > return ret;
> > }
> >
> >
>
> No. I don't agree on this. Your fix can't resolve all potential issues.
>
> i2c = kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
> if (!i2c) {
> ret = -ENOMEM;
> goto emalloc;
> }
>
> ret = i2c_pxa_probe_dt(dev, i2c, _type);
> if (ret > 0)
> ret = i2c_pxa_probe_pdata(dev, i2c, _type);
> if (ret < 0)
> goto eclk;
>
> res = platform_get_resource(dev, IORESOURCE_MEM, 0);
> irq = platform_get_irq(dev, 0);
> if (res == NULL || irq < 0) {
> ret = -ENODEV;
> goto eclk;
> }
>
> if (!request_mem_region(res->start, resource_size(res), res->name)) {
> ret = -ENOMEM;
> goto eclk;
> }
>
> We shouldn't jump to eclk for these error cases. Then we needn't to add
> checking on res.
So what do you suggest to do for these error cases?
- cong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
On Tue, Feb 05, 2013 at 09:14:08AM +0800, Haojian Zhuang wrote:
On Tue, Feb 5, 2013 at 8:05 AM, Cong Ding ding...@gmail.com wrote:
If it goes to eclk through line 1107, the variable res would be NULL. It
will
cause a null pointer dereference error if we call release_mem_region.
Signed-off-by: Cong Ding ding...@gmail.com
---
drivers/i2c/busses/i2c-pxa.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..00df535 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1211,7 +1211,8 @@ eremap:
eclk:
kfree(i2c);
emalloc:
- release_mem_region(res-start, resource_size(res));
+ if (res)
+ release_mem_region(res-start, resource_size(res));
return ret;
}
No. I don't agree on this. Your fix can't resolve all potential issues.
i2c = kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
if (!i2c) {
ret = -ENOMEM;
goto emalloc;
}
ret = i2c_pxa_probe_dt(dev, i2c, i2c_type);
if (ret 0)
ret = i2c_pxa_probe_pdata(dev, i2c, i2c_type);
if (ret 0)
goto eclk;
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
irq = platform_get_irq(dev, 0);
if (res == NULL || irq 0) {
ret = -ENODEV;
goto eclk;
}
if (!request_mem_region(res-start, resource_size(res), res-name)) {
ret = -ENOMEM;
goto eclk;
}
We shouldn't jump to eclk for these error cases. Then we needn't to add
checking on res.
So what do you suggest to do for these error cases?
- cong
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
If it goes to eclk through line 1107, the variable res would be NULL. It will cause a null pointer dereference error if we call release_mem_region. Signed-off-by: Cong Ding --- drivers/i2c/busses/i2c-pxa.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c index 1034d93..00df535 100644 --- a/drivers/i2c/busses/i2c-pxa.c +++ b/drivers/i2c/busses/i2c-pxa.c @@ -1211,7 +1211,8 @@ eremap: eclk: kfree(i2c); emalloc: - release_mem_region(res->start, resource_size(res)); + if (res) + release_mem_region(res->start, resource_size(res)); return ret; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
On Tue, Feb 05, 2013 at 08:47:10AM +0900, Kyungmin Park wrote: > Hi, > > On Tue, Feb 5, 2013 at 7:11 AM, Cong Ding wrote: > > If it goes to eclk through line 1107, the variable res would be NULL. It > > will > > cause a null pointer dereference error if we call release_mem_region. > > > > Signed-off-by: Cong Ding > > --- > > drivers/i2c/busses/i2c-pxa.c |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c > > index 1034d93..eadf1a4 100644 > > --- a/drivers/i2c/busses/i2c-pxa.c > > +++ b/drivers/i2c/busses/i2c-pxa.c > > @@ -1211,7 +1211,8 @@ eremap: > > eclk: > > kfree(i2c); > > emalloc: > > - release_mem_region(res->start, resource_size(res)); > > + if (!res) > if (res)? > It's not match with description. and it seems wrong. sorry my fault. will send version 2. - cong > > Thank you, > Kyungmin Park > > + release_mem_region(res->start, resource_size(res)); > > return ret; > > } > > > > -- > > 1.7.9.5 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] infiniband: hw/cxgb3/iwch_provider.c: fix uninitialized variable issue
The variable npages might be used uninitialized in line 594.
Signed-off-by: Cong Ding
---
drivers/infiniband/hw/cxgb3/iwch_provider.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index 145d82a..90ce483 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -559,7 +559,7 @@ static int iwch_reregister_phys_mem(struct ib_mr *mr,
__be64 *page_list = NULL;
int shift = 0;
u64 total_size;
- int npages;
+ int npages = 0;
int ret;
PDBG("%s ib_mr %p ib_pd %p\n", __func__, mr, pd);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: wireless/rtlwifi: fix uninitialized variable issue
The use of variable packet_beacon might be uninitialized in the two files, which is same as this patch: https://patchwork.kernel.org/patch/2006711/ Signed-off-by: Cong Ding --- drivers/net/wireless/rtlwifi/rtl8192ce/trx.c |2 +- drivers/net/wireless/rtlwifi/rtl8192cu/mac.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c index c31795e..da0e902 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c @@ -488,7 +488,7 @@ static void _rtl92ce_translate_rx_signal_stuff(struct ieee80211_hw *hw, u8 *praddr; __le16 fc; u16 type, c_fc; - bool packet_matchbssid, packet_toself, packet_beacon; + bool packet_matchbssid, packet_toself, packet_beacon = false; tmp_buf = skb->data + pstats->rx_drvinfo_size + pstats->rx_bufshift; diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c b/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c index 32ff959..85b6bdb 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c @@ -1084,7 +1084,7 @@ void rtl92c_translate_rx_signal_stuff(struct ieee80211_hw *hw, u8 *praddr; __le16 fc; u16 type, cpu_fc; - bool packet_matchbssid, packet_toself, packet_beacon; + bool packet_matchbssid, packet_toself, packet_beacon = false; tmp_buf = skb->data + pstats->rx_drvinfo_size + pstats->rx_bufshift; hdr = (struct ieee80211_hdr *)tmp_buf; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: wireless/rtlwifi: fix uninitialized variable issue
The use of variable packet_beacon might be uninitialized in the two files, which is same as this patch: https://patchwork.kernel.org/patch/2006711/ Signed-off-by: Cong Ding ding...@gmail.com --- drivers/net/wireless/rtlwifi/rtl8192ce/trx.c |2 +- drivers/net/wireless/rtlwifi/rtl8192cu/mac.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c index c31795e..da0e902 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.c @@ -488,7 +488,7 @@ static void _rtl92ce_translate_rx_signal_stuff(struct ieee80211_hw *hw, u8 *praddr; __le16 fc; u16 type, c_fc; - bool packet_matchbssid, packet_toself, packet_beacon; + bool packet_matchbssid, packet_toself, packet_beacon = false; tmp_buf = skb-data + pstats-rx_drvinfo_size + pstats-rx_bufshift; diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c b/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c index 32ff959..85b6bdb 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c @@ -1084,7 +1084,7 @@ void rtl92c_translate_rx_signal_stuff(struct ieee80211_hw *hw, u8 *praddr; __le16 fc; u16 type, cpu_fc; - bool packet_matchbssid, packet_toself, packet_beacon; + bool packet_matchbssid, packet_toself, packet_beacon = false; tmp_buf = skb-data + pstats-rx_drvinfo_size + pstats-rx_bufshift; hdr = (struct ieee80211_hdr *)tmp_buf; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] infiniband: hw/cxgb3/iwch_provider.c: fix uninitialized variable issue
The variable npages might be used uninitialized in line 594. Signed-off-by: Cong Ding ding...@gmail.com --- drivers/infiniband/hw/cxgb3/iwch_provider.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c b/drivers/infiniband/hw/cxgb3/iwch_provider.c index 145d82a..90ce483 100644 --- a/drivers/infiniband/hw/cxgb3/iwch_provider.c +++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c @@ -559,7 +559,7 @@ static int iwch_reregister_phys_mem(struct ib_mr *mr, __be64 *page_list = NULL; int shift = 0; u64 total_size; - int npages; + int npages = 0; int ret; PDBG(%s ib_mr %p ib_pd %p\n, __func__, mr, pd); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
On Tue, Feb 05, 2013 at 08:47:10AM +0900, Kyungmin Park wrote: Hi, On Tue, Feb 5, 2013 at 7:11 AM, Cong Ding ding...@gmail.com wrote: If it goes to eclk through line 1107, the variable res would be NULL. It will cause a null pointer dereference error if we call release_mem_region. Signed-off-by: Cong Ding ding...@gmail.com --- drivers/i2c/busses/i2c-pxa.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c index 1034d93..eadf1a4 100644 --- a/drivers/i2c/busses/i2c-pxa.c +++ b/drivers/i2c/busses/i2c-pxa.c @@ -1211,7 +1211,8 @@ eremap: eclk: kfree(i2c); emalloc: - release_mem_region(res-start, resource_size(res)); + if (!res) if (res)? It's not match with description. and it seems wrong. sorry my fault. will send version 2. - cong Thank you, Kyungmin Park + release_mem_region(res-start, resource_size(res)); return ret; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
If it goes to eclk through line 1107, the variable res would be NULL. It will cause a null pointer dereference error if we call release_mem_region. Signed-off-by: Cong Ding ding...@gmail.com --- drivers/i2c/busses/i2c-pxa.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c index 1034d93..00df535 100644 --- a/drivers/i2c/busses/i2c-pxa.c +++ b/drivers/i2c/busses/i2c-pxa.c @@ -1211,7 +1211,8 @@ eremap: eclk: kfree(i2c); emalloc: - release_mem_region(res-start, resource_size(res)); + if (res) + release_mem_region(res-start, resource_size(res)); return ret; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/boot] x86/boot: Fix minor fd leakage in tools/relocs.c
Commit-ID: 65315d4889d403ea025081d8ca85ddf7b9c10f39
Gitweb: http://git.kernel.org/tip/65315d4889d403ea025081d8ca85ddf7b9c10f39
Author: Cong Ding
AuthorDate: Mon, 14 Jan 2013 17:13:35 +
Committer: H. Peter Anvin
CommitDate: Sun, 27 Jan 2013 10:24:28 -0800
x86/boot: Fix minor fd leakage in tools/relocs.c
The opened file should be closed.
Signed-off-by: Cong Ding
Cc: Kusanagi Kouichi
Cc: Jarkko Sakkinen
Cc: Jiri Kosina
Cc: Matt Fleming
Link:
http://lkml.kernel.org/r/1358183628-27784-1-git-send-email-ding...@gmail.com
Signed-off-by: Ingo Molnar
---
arch/x86/tools/relocs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5a1847d..79d67bd 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -814,12 +814,14 @@ int main(int argc, char **argv)
read_relocs(fp);
if (show_absolute_syms) {
print_absolute_symbols();
- return 0;
+ goto out;
}
if (show_absolute_relocs) {
print_absolute_relocs();
- return 0;
+ goto out;
}
emit_relocs(as_text, use_real_mode);
+out:
+ fclose(fp);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend] sched: fix compilation warning
the following compilation warning is caused by Commit-ID: c566e8e9e44b72b53091da20e2dedefc730f2ee2 kernel/sched/debug.c: In function ‘print_cfs_rq’: kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long int’ [-Wformat] kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat] where function atomic64_read returns long long int, but %ld was used in the printf Signed-off-by: Cong Ding --- resend because no reply for Message-Id: <1354727440-20157-1-git-send-email-ding...@gmail.com> kernel/sched/debug.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index 2cd3c1b..83ec463 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -222,7 +222,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq) cfs_rq->runnable_load_avg); SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg", cfs_rq->blocked_load_avg); - SEQ_printf(m, " .%-30s: %ld\n", "tg_load_avg", + SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg", atomic64_read(_rq->tg->load_avg)); SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib", cfs_rq->tg_load_contrib); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend] sched: fix compilation warning
the following compilation warning is caused by Commit-ID: c566e8e9e44b72b53091da20e2dedefc730f2ee2 kernel/sched/debug.c: In function ‘print_cfs_rq’: kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long int’ [-Wformat] kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat] where function atomic64_read returns long long int, but %ld was used in the printf Signed-off-by: Cong Ding ding...@gmail.com --- resend because no reply for Message-Id: 1354727440-20157-1-git-send-email-ding...@gmail.com kernel/sched/debug.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index 2cd3c1b..83ec463 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -222,7 +222,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq) cfs_rq-runnable_load_avg); SEQ_printf(m, .%-30s: %lld\n, blocked_load_avg, cfs_rq-blocked_load_avg); - SEQ_printf(m, .%-30s: %ld\n, tg_load_avg, + SEQ_printf(m, .%-30s: %lld\n, tg_load_avg, atomic64_read(cfs_rq-tg-load_avg)); SEQ_printf(m, .%-30s: %lld\n, tg_load_contrib, cfs_rq-tg_load_contrib); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/boot] x86/boot: Fix minor fd leakage in tools/relocs.c
Commit-ID: 65315d4889d403ea025081d8ca85ddf7b9c10f39
Gitweb: http://git.kernel.org/tip/65315d4889d403ea025081d8ca85ddf7b9c10f39
Author: Cong Ding ding...@gmail.com
AuthorDate: Mon, 14 Jan 2013 17:13:35 +
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Sun, 27 Jan 2013 10:24:28 -0800
x86/boot: Fix minor fd leakage in tools/relocs.c
The opened file should be closed.
Signed-off-by: Cong Ding ding...@gmail.com
Cc: Kusanagi Kouichi sl...@ac.auone-net.jp
Cc: Jarkko Sakkinen jarkko.sakki...@intel.com
Cc: Jiri Kosina jkos...@suse.cz
Cc: Matt Fleming matt.flem...@intel.com
Link:
http://lkml.kernel.org/r/1358183628-27784-1-git-send-email-ding...@gmail.com
Signed-off-by: Ingo Molnar mi...@kernel.org
---
arch/x86/tools/relocs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5a1847d..79d67bd 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -814,12 +814,14 @@ int main(int argc, char **argv)
read_relocs(fp);
if (show_absolute_syms) {
print_absolute_symbols();
- return 0;
+ goto out;
}
if (show_absolute_relocs) {
print_absolute_relocs();
- return 0;
+ goto out;
}
emit_relocs(as_text, use_real_mode);
+out:
+ fclose(fp);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] btrfs: fix potential null pointer dereference bug
On Thu, Jan 24, 2013 at 10:34:20AM -0500, Josef Bacik wrote:
> On Sat, Jan 19, 2013 at 08:27:45AM -0700, Cong Ding wrote:
> > The bug happens when rb_node == NULL. It causes variable node to be NULL and
> > then the NULL pointer is dereferenced this line:
> > BUG_ON((struct btrfs_root *)node->data != root);
> >
> > Based on my analysis, function tree_search should not return NULL to
> > variable
> > rb_node in this case (otherwise here has to be something unknown thing
> > wrong),
> > so I replace "if (rb_node)" with UG_ON(!rb_node).
> >
> > Signed-off-by: Cong Ding
>
> I don't want to add more BUG_ON()'s, just return an error.
But rb_node really has no chance to be 0, so I think we should use BUG_ON
rather than return an error. If we return an error number here, its caller
should check the returned value and call BUG_ON(ret) - it makes no difference.
The file system doesn't have any way to handle this kind of error (and I think
if it happens, there must be some hardware error or some other program
directly operates on the file system bypassing linux system call). If you
don't want to add more BUG_ON, I suggest to check variable "node" in the
existing BUG_ON as the following code.
- BUG_ON((struct btrfs_root *)node->data != root);
+ BUG_ON(!node || (struct btrfs_root *)node->data != root);
What's your opinion, or do you have a better solution?
Thanks,
- cong
>From 3a5b4df67dd177b7cbc61c555349fd7e87ef6b54 Mon Sep 17 00:00:00 2001
From: Cong Ding
Date: Thu, 24 Jan 2013 18:30:45 -0500
Subject: [PATCH] btrfs: fix potential null pointer dereference bug
The bug happens when rb_node == NULL. It causes variable node to be NULL and
then the NULL pointer is dereferenced this line:
BUG_ON((struct btrfs_root *)node->data != root);
So we check node before the dereference.
Signed-off-by: Cong Ding
---
fs/btrfs/relocation.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 17c306b..938b037 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1269,7 +1269,7 @@ static int __update_reloc_root(struct btrfs_root *root,
int del)
}
spin_unlock(>reloc_root_tree.lock);
- BUG_ON((struct btrfs_root *)node->data != root);
+ BUG_ON(!node || (struct btrfs_root *)node->data != root);
if (!del) {
spin_lock(>reloc_root_tree.lock);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/platform] x86/apb/timer: Remove unnecessary "if"
Commit-ID: b9975dabe3f0a6e4d1af52c47f66b5558df207a3
Gitweb: http://git.kernel.org/tip/b9975dabe3f0a6e4d1af52c47f66b5558df207a3
Author: Cong Ding
AuthorDate: Mon, 14 Jan 2013 22:39:18 +0100
Committer: Ingo Molnar
CommitDate: Thu, 24 Jan 2013 13:03:26 +0100
x86/apb/timer: Remove unnecessary "if"
adev has no chance to be NULL, so we don't need to check it. It
is also dereferenced just before the check .
Signed-off-by: Cong Ding
Cc: Sasha Levin
Link:
http://lkml.kernel.org/r/1358199561-15518-1-git-send-email-ding...@gmail.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apb_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apb_timer.c b/arch/x86/kernel/apb_timer.c
index afdc3f75..cf92735 100644
--- a/arch/x86/kernel/apb_timer.c
+++ b/arch/x86/kernel/apb_timer.c
@@ -240,7 +240,7 @@ static int apbt_cpuhp_notify(struct notifier_block *n,
dw_apb_clockevent_pause(adev->timer);
if (system_state == SYSTEM_RUNNING) {
pr_debug("skipping APBT CPU %lu offline\n", cpu);
- } else if (adev) {
+ } else {
pr_debug("APBT clockevent for cpu %lu offline\n", cpu);
dw_apb_clockevent_stop(adev->timer);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/boot] x86/boot: Fix minor fd leakage in tools/relocs.c
Commit-ID: 585376216a829d1ddfb3e57cb50c72c23adb484f
Gitweb: http://git.kernel.org/tip/585376216a829d1ddfb3e57cb50c72c23adb484f
Author: Cong Ding
AuthorDate: Mon, 14 Jan 2013 17:13:35 +
Committer: Ingo Molnar
CommitDate: Thu, 24 Jan 2013 13:07:23 +0100
x86/boot: Fix minor fd leakage in tools/relocs.c
The opened file should be closed.
Signed-off-by: Cong Ding
Cc: Kusanagi Kouichi
Cc: Jarkko Sakkinen
Cc: Jiri Kosina
Cc: Matt Fleming
Link:
http://lkml.kernel.org/r/1358183628-27784-1-git-send-email-ding...@gmail.com
Signed-off-by: Ingo Molnar
---
arch/x86/tools/relocs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5a1847d..79d67bd 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -814,12 +814,14 @@ int main(int argc, char **argv)
read_relocs(fp);
if (show_absolute_syms) {
print_absolute_symbols();
- return 0;
+ goto out;
}
if (show_absolute_relocs) {
print_absolute_relocs();
- return 0;
+ goto out;
}
emit_relocs(as_text, use_real_mode);
+out:
+ fclose(fp);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/boot] x86/boot: Fix minor fd leakage in tools/relocs.c
Commit-ID: 585376216a829d1ddfb3e57cb50c72c23adb484f
Gitweb: http://git.kernel.org/tip/585376216a829d1ddfb3e57cb50c72c23adb484f
Author: Cong Ding ding...@gmail.com
AuthorDate: Mon, 14 Jan 2013 17:13:35 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 24 Jan 2013 13:07:23 +0100
x86/boot: Fix minor fd leakage in tools/relocs.c
The opened file should be closed.
Signed-off-by: Cong Ding ding...@gmail.com
Cc: Kusanagi Kouichi sl...@ac.auone-net.jp
Cc: Jarkko Sakkinen jarkko.sakki...@intel.com
Cc: Jiri Kosina jkos...@suse.cz
Cc: Matt Fleming matt.flem...@intel.com
Link:
http://lkml.kernel.org/r/1358183628-27784-1-git-send-email-ding...@gmail.com
Signed-off-by: Ingo Molnar mi...@kernel.org
---
arch/x86/tools/relocs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5a1847d..79d67bd 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -814,12 +814,14 @@ int main(int argc, char **argv)
read_relocs(fp);
if (show_absolute_syms) {
print_absolute_symbols();
- return 0;
+ goto out;
}
if (show_absolute_relocs) {
print_absolute_relocs();
- return 0;
+ goto out;
}
emit_relocs(as_text, use_real_mode);
+out:
+ fclose(fp);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/platform] x86/apb/timer: Remove unnecessary if
Commit-ID: b9975dabe3f0a6e4d1af52c47f66b5558df207a3
Gitweb: http://git.kernel.org/tip/b9975dabe3f0a6e4d1af52c47f66b5558df207a3
Author: Cong Ding ding...@gmail.com
AuthorDate: Mon, 14 Jan 2013 22:39:18 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 24 Jan 2013 13:03:26 +0100
x86/apb/timer: Remove unnecessary if
adev has no chance to be NULL, so we don't need to check it. It
is also dereferenced just before the check .
Signed-off-by: Cong Ding ding...@gmail.com
Cc: Sasha Levin sasha.le...@oracle.com
Link:
http://lkml.kernel.org/r/1358199561-15518-1-git-send-email-ding...@gmail.com
Signed-off-by: Ingo Molnar mi...@kernel.org
---
arch/x86/kernel/apb_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apb_timer.c b/arch/x86/kernel/apb_timer.c
index afdc3f75..cf92735 100644
--- a/arch/x86/kernel/apb_timer.c
+++ b/arch/x86/kernel/apb_timer.c
@@ -240,7 +240,7 @@ static int apbt_cpuhp_notify(struct notifier_block *n,
dw_apb_clockevent_pause(adev-timer);
if (system_state == SYSTEM_RUNNING) {
pr_debug(skipping APBT CPU %lu offline\n, cpu);
- } else if (adev) {
+ } else {
pr_debug(APBT clockevent for cpu %lu offline\n, cpu);
dw_apb_clockevent_stop(adev-timer);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] btrfs: fix potential null pointer dereference bug
On Thu, Jan 24, 2013 at 10:34:20AM -0500, Josef Bacik wrote:
On Sat, Jan 19, 2013 at 08:27:45AM -0700, Cong Ding wrote:
The bug happens when rb_node == NULL. It causes variable node to be NULL and
then the NULL pointer is dereferenced this line:
BUG_ON((struct btrfs_root *)node-data != root);
Based on my analysis, function tree_search should not return NULL to
variable
rb_node in this case (otherwise here has to be something unknown thing
wrong),
so I replace if (rb_node) with UG_ON(!rb_node).
Signed-off-by: Cong Ding ding...@gmail.com
I don't want to add more BUG_ON()'s, just return an error.
But rb_node really has no chance to be 0, so I think we should use BUG_ON
rather than return an error. If we return an error number here, its caller
should check the returned value and call BUG_ON(ret) - it makes no difference.
The file system doesn't have any way to handle this kind of error (and I think
if it happens, there must be some hardware error or some other program
directly operates on the file system bypassing linux system call). If you
don't want to add more BUG_ON, I suggest to check variable node in the
existing BUG_ON as the following code.
- BUG_ON((struct btrfs_root *)node-data != root);
+ BUG_ON(!node || (struct btrfs_root *)node-data != root);
What's your opinion, or do you have a better solution?
Thanks,
- cong
From 3a5b4df67dd177b7cbc61c555349fd7e87ef6b54 Mon Sep 17 00:00:00 2001
From: Cong Ding ding...@gmail.com
Date: Thu, 24 Jan 2013 18:30:45 -0500
Subject: [PATCH] btrfs: fix potential null pointer dereference bug
The bug happens when rb_node == NULL. It causes variable node to be NULL and
then the NULL pointer is dereferenced this line:
BUG_ON((struct btrfs_root *)node-data != root);
So we check node before the dereference.
Signed-off-by: Cong Ding ding...@gmail.com
---
fs/btrfs/relocation.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 17c306b..938b037 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1269,7 +1269,7 @@ static int __update_reloc_root(struct btrfs_root *root,
int del)
}
spin_unlock(rc-reloc_root_tree.lock);
- BUG_ON((struct btrfs_root *)node-data != root);
+ BUG_ON(!node || (struct btrfs_root *)node-data != root);
if (!del) {
spin_lock(rc-reloc_root_tree.lock);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LKML and other vger MLs - which provider...
On Wed, Jan 23, 2013 at 10:32:39PM +0100, Guennadi Liakhovetski wrote: > Hi David > > In short: I'm looking for a (free) email provider to use for my > vger.kernel.org subscriptions. Read a thread on google+ with your > participation and was wondering whether you could recommend one or knew of > a way to get an @infradead.org address, although that doesn't seem to be > safe enough either any more... > > The long story: gmx.de, that I'm using as my "identity" address, got me > unsubscribed multiple times from vger MLs. Even though not wanting to give > the big G even more power, gmail has worked pretty stably, without > dropping me out. However, recently I've detected a flaw with them (known > to some too, I'm sure): they only deliver one copy of each mail. So, if a > patch series is sent to more than one vger ML, I end up with some mails > from it in my, say, mmc folder and with other in the linux-sh folder. I suggest to use Gmail filter rather than mutt filter. The difference is that Gmail filter can mark one email with multiple labels, which means you can see the same email in two or more folders (called labels in Gmail) even there is only one copy stored in Gmail. btw, the unread sign of one email in different labels is shared. I think this feature is quite good, though I hate Gmail web version doesn't follow the RFC about thread. - cong > Since I don't see a way to fix that with gmail (yes, I've sent a request > to them, but I'm not very hopeful), I'd be happy to move to another > provider. So, any recommendations would be welcome. I know this has been > discussed multiple times before, but unfortunately I don't find those > threads again. Might be a good thing to put on vger info pages. > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ceph/osdmap.c: fix undefined behavior when using snprintf()
On Wed, Jan 23, 2013 at 10:48:07AM -0600, Alex Elder wrote:
> On 01/22/2013 01:20 PM, Cong Ding wrote:
> > The variable "str" is used as both the source and destination in function
> > snprintf(), which is undefined behavior based on C11. The original
> > description
> > in C11 is:
> > "If copying takes place between objects that
> > overlap, the behavior is undefined."
>
> Yes, this was an ill-advised thing to do in this function.
>
> In fact, the only place this function is used (in osdmap_show()),
> the non-static buffer was not initialized before the call. (It
> might happen to work because the same stack space was getting
> reused each time through the loop. Ew!)
>
> This is just an awful couple of functions.
>
> > And, the function of ceph_osdmap_state_str() is to return the osdmap state,
> > so
> > it should return "doesn't exist" when all the conditions are not satisfied.
> > I
> > fix it in this patch.
> >
> > Based on C11, snprintf() does nothing if n==0:
> > "If n is zero, nothing is written, and s may be a
> > null pointer. Otherwise, output characters beyond
> > the n-1st are discarded rather than being written to
> > the array, and a null character is written at the
> > end of the characters actually written into the
> > array."
> > so I remove the unnecessary check of len (because it is not a busy path and
> > saves a few lines of code).
>
> True. But since you know it's not going to do anything why
> not only make the call if len is non-zero? I.e.:
>
> else if (len)
> snprintf(str, len, "doesn't exist");
>
> With your permission I'll make this change and will commit
> this for you. OK?
It's fine, thanks. But I think it's better to check len in the beginning
because other conditions also call snprintf with parameter len. Like this:
if (!len)
return str;
if ((state & CEPH_OSD_EXISTS) && (state & CEPH_OSD_UP))
snprintf(str, len, "exists, up");
else if (state & CEPH_OSD_EXISTS)
snprintf(str, len, "exists");
else if (state & CEPH_OSD_UP)
snprintf(str, len, "up");
else
snprintf(str, len, "doesn't exist");
return str;
or like this:
if (len) {
if ((state & CEPH_OSD_EXISTS) && (state & CEPH_OSD_UP))
snprintf(str, len, "exists, up");
else if (state & CEPH_OSD_EXISTS)
snprintf(str, len, "exists");
else if (state & CEPH_OSD_UP)
snprintf(str, len, "up");
else
snprintf(str, len, "doesn't exist");
}
return str;
Thanks,
- cong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ceph/osdmap.c: fix undefined behavior when using snprintf()
On Wed, Jan 23, 2013 at 10:48:07AM -0600, Alex Elder wrote:
On 01/22/2013 01:20 PM, Cong Ding wrote:
The variable str is used as both the source and destination in function
snprintf(), which is undefined behavior based on C11. The original
description
in C11 is:
If copying takes place between objects that
overlap, the behavior is undefined.
Yes, this was an ill-advised thing to do in this function.
In fact, the only place this function is used (in osdmap_show()),
the non-static buffer was not initialized before the call. (It
might happen to work because the same stack space was getting
reused each time through the loop. Ew!)
This is just an awful couple of functions.
And, the function of ceph_osdmap_state_str() is to return the osdmap state,
so
it should return doesn't exist when all the conditions are not satisfied.
I
fix it in this patch.
Based on C11, snprintf() does nothing if n==0:
If n is zero, nothing is written, and s may be a
null pointer. Otherwise, output characters beyond
the n-1st are discarded rather than being written to
the array, and a null character is written at the
end of the characters actually written into the
array.
so I remove the unnecessary check of len (because it is not a busy path and
saves a few lines of code).
True. But since you know it's not going to do anything why
not only make the call if len is non-zero? I.e.:
else if (len)
snprintf(str, len, doesn't exist);
With your permission I'll make this change and will commit
this for you. OK?
It's fine, thanks. But I think it's better to check len in the beginning
because other conditions also call snprintf with parameter len. Like this:
if (!len)
return str;
if ((state CEPH_OSD_EXISTS) (state CEPH_OSD_UP))
snprintf(str, len, exists, up);
else if (state CEPH_OSD_EXISTS)
snprintf(str, len, exists);
else if (state CEPH_OSD_UP)
snprintf(str, len, up);
else
snprintf(str, len, doesn't exist);
return str;
or like this:
if (len) {
if ((state CEPH_OSD_EXISTS) (state CEPH_OSD_UP))
snprintf(str, len, exists, up);
else if (state CEPH_OSD_EXISTS)
snprintf(str, len, exists);
else if (state CEPH_OSD_UP)
snprintf(str, len, up);
else
snprintf(str, len, doesn't exist);
}
return str;
Thanks,
- cong
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LKML and other vger MLs - which provider...
On Wed, Jan 23, 2013 at 10:32:39PM +0100, Guennadi Liakhovetski wrote: Hi David In short: I'm looking for a (free) email provider to use for my vger.kernel.org subscriptions. Read a thread on google+ with your participation and was wondering whether you could recommend one or knew of a way to get an @infradead.org address, although that doesn't seem to be safe enough either any more... The long story: gmx.de, that I'm using as my identity address, got me unsubscribed multiple times from vger MLs. Even though not wanting to give the big G even more power, gmail has worked pretty stably, without dropping me out. However, recently I've detected a flaw with them (known to some too, I'm sure): they only deliver one copy of each mail. So, if a patch series is sent to more than one vger ML, I end up with some mails from it in my, say, mmc folder and with other in the linux-sh folder. I suggest to use Gmail filter rather than mutt filter. The difference is that Gmail filter can mark one email with multiple labels, which means you can see the same email in two or more folders (called labels in Gmail) even there is only one copy stored in Gmail. btw, the unread sign of one email in different labels is shared. I think this feature is quite good, though I hate Gmail web version doesn't follow the RFC about thread. - cong Since I don't see a way to fix that with gmail (yes, I've sent a request to them, but I'm not very hopeful), I'd be happy to move to another provider. So, any recommendations would be welcome. I know this has been discussed multiple times before, but unfortunately I don't find those threads again. Might be a good thing to put on vger info pages. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs/cifs/cifs_dfs_ref.c: fix potential memory leakage
When it goes to error through line 144, the memory allocated to *devname is not freed, and the caller doesn't free it either in line 250. So we free the memroy of *devname in function cifs_compose_mount_options() when it goes to error. Signed-off-by: Cong Ding --- fs/cifs/cifs_dfs_ref.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/cifs/cifs_dfs_ref.c b/fs/cifs/cifs_dfs_ref.c index ce5cbd7..210fce2 100644 --- a/fs/cifs/cifs_dfs_ref.c +++ b/fs/cifs/cifs_dfs_ref.c @@ -226,6 +226,8 @@ compose_mount_options_out: compose_mount_options_err: kfree(mountdata); mountdata = ERR_PTR(rc); + kfree(*devname); + *devname = NULL; goto compose_mount_options_out; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/ceph/osdmap.c: fix undefined behavior when using snprintf()
The variable "str" is used as both the source and destination in function
snprintf(), which is undefined behavior based on C11. The original description
in C11 is:
"If copying takes place between objects that
overlap, the behavior is undefined."
And, the function of ceph_osdmap_state_str() is to return the osdmap state, so
it should return "doesn't exist" when all the conditions are not satisfied. I
fix it in this patch.
Based on C11, snprintf() does nothing if n==0:
"If n is zero, nothing is written, and s may be a
null pointer. Otherwise, output characters beyond
the n-1st are discarded rather than being written to
the array, and a null character is written at the
end of the characters actually written into the
array."
so I remove the unnecessary check of len (because it is not a busy path and
saves a few lines of code).
Signed-off-by: Cong Ding
---
net/ceph/osdmap.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index de73214..3131a99d3 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -13,26 +13,15 @@
char *ceph_osdmap_state_str(char *str, int len, int state)
{
- int flag = 0;
-
- if (!len)
- goto done;
-
- *str = '\0';
- if (state) {
- if (state & CEPH_OSD_EXISTS) {
- snprintf(str, len, "exists");
- flag = 1;
- }
- if (state & CEPH_OSD_UP) {
- snprintf(str, len, "%s%s%s", str, (flag ? ", " : ""),
-"up");
- flag = 1;
- }
- } else {
+ if ((state & CEPH_OSD_EXISTS) && (state & CEPH_OSD_UP))
+ snprintf(str, len, "exists, up");
+ else if (state & CEPH_OSD_EXISTS)
+ snprintf(str, len, "exists");
+ else if (state & CEPH_OSD_UP)
+ snprintf(str, len, "up");
+ else
snprintf(str, len, "doesn't exist");
- }
-done:
+
return str;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: dma.c: fix memory leakage
On Sun, Jan 20, 2013 at 04:24:49PM -0600, Rob Herring wrote:
> On 01/19/2013 07:06 AM, Cong Ding wrote:
> > The memory allocated to ofdma might be a leakage when error occurs.
> >
> > Signed-off-by: Cong Ding
>
> You need to send this to whomever is working on DMA bindings.
Thank you bob, I added Vinod the the receiver list.
- cong
>
> > ---
> > drivers/of/dma.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/of/dma.c b/drivers/of/dma.c
> > index 59631b2..583e50e3 100644
> > --- a/drivers/of/dma.c
> > +++ b/drivers/of/dma.c
> > @@ -107,6 +107,7 @@ int of_dma_controller_register(struct device_node *np,
> > if (!nbcells) {
> > pr_err("%s: #dma-cells property is missing or invalid\n",
> >__func__);
> > + kfree(ofdma);
> > return -EINVAL;
> > }
> >
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: dma.c: fix memory leakage
On Sun, Jan 20, 2013 at 04:24:49PM -0600, Rob Herring wrote:
On 01/19/2013 07:06 AM, Cong Ding wrote:
The memory allocated to ofdma might be a leakage when error occurs.
Signed-off-by: Cong Ding ding...@gmail.com
You need to send this to whomever is working on DMA bindings.
Thank you bob, I added Vinod the the receiver list.
- cong
---
drivers/of/dma.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 59631b2..583e50e3 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -107,6 +107,7 @@ int of_dma_controller_register(struct device_node *np,
if (!nbcells) {
pr_err(%s: #dma-cells property is missing or invalid\n,
__func__);
+ kfree(ofdma);
return -EINVAL;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/ceph/osdmap.c: fix undefined behavior when using snprintf()
The variable str is used as both the source and destination in function
snprintf(), which is undefined behavior based on C11. The original description
in C11 is:
If copying takes place between objects that
overlap, the behavior is undefined.
And, the function of ceph_osdmap_state_str() is to return the osdmap state, so
it should return doesn't exist when all the conditions are not satisfied. I
fix it in this patch.
Based on C11, snprintf() does nothing if n==0:
If n is zero, nothing is written, and s may be a
null pointer. Otherwise, output characters beyond
the n-1st are discarded rather than being written to
the array, and a null character is written at the
end of the characters actually written into the
array.
so I remove the unnecessary check of len (because it is not a busy path and
saves a few lines of code).
Signed-off-by: Cong Ding ding...@gmail.com
---
net/ceph/osdmap.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index de73214..3131a99d3 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -13,26 +13,15 @@
char *ceph_osdmap_state_str(char *str, int len, int state)
{
- int flag = 0;
-
- if (!len)
- goto done;
-
- *str = '\0';
- if (state) {
- if (state CEPH_OSD_EXISTS) {
- snprintf(str, len, exists);
- flag = 1;
- }
- if (state CEPH_OSD_UP) {
- snprintf(str, len, %s%s%s, str, (flag ? , : ),
-up);
- flag = 1;
- }
- } else {
+ if ((state CEPH_OSD_EXISTS) (state CEPH_OSD_UP))
+ snprintf(str, len, exists, up);
+ else if (state CEPH_OSD_EXISTS)
+ snprintf(str, len, exists);
+ else if (state CEPH_OSD_UP)
+ snprintf(str, len, up);
+ else
snprintf(str, len, doesn't exist);
- }
-done:
+
return str;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs/cifs/cifs_dfs_ref.c: fix potential memory leakage
When it goes to error through line 144, the memory allocated to *devname is not freed, and the caller doesn't free it either in line 250. So we free the memroy of *devname in function cifs_compose_mount_options() when it goes to error. Signed-off-by: Cong Ding ding...@gmail.com --- fs/cifs/cifs_dfs_ref.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/cifs/cifs_dfs_ref.c b/fs/cifs/cifs_dfs_ref.c index ce5cbd7..210fce2 100644 --- a/fs/cifs/cifs_dfs_ref.c +++ b/fs/cifs/cifs_dfs_ref.c @@ -226,6 +226,8 @@ compose_mount_options_out: compose_mount_options_err: kfree(mountdata); mountdata = ERR_PTR(rc); + kfree(*devname); + *devname = NULL; goto compose_mount_options_out; } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] btrfs: fix potential null pointer dereference bug
The bug happens when rb_node == NULL. It causes variable node to be NULL and
then the NULL pointer is dereferenced this line:
BUG_ON((struct btrfs_root *)node->data != root);
Based on my analysis, function tree_search should not return NULL to variable
rb_node in this case (otherwise here has to be something unknown thing wrong),
so I replace "if (rb_node)" with UG_ON(!rb_node).
Signed-off-by: Cong Ding
---
fs/btrfs/relocation.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 17c306b..d674671 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1263,10 +1263,11 @@ static int __update_reloc_root(struct btrfs_root *root,
int del)
spin_lock(>reloc_root_tree.lock);
rb_node = tree_search(>reloc_root_tree.rb_root,
root->commit_root->start);
- if (rb_node) {
- node = rb_entry(rb_node, struct mapping_node, rb_node);
- rb_erase(>rb_node, >reloc_root_tree.rb_root);
- }
+ BUG_ON(!rb_node);
+
+ node = rb_entry(rb_node, struct mapping_node, rb_node);
+ rb_erase(>rb_node, >reloc_root_tree.rb_root);
+
spin_unlock(>reloc_root_tree.lock);
BUG_ON((struct btrfs_root *)node->data != root);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: dma.c: fix memory leakage
The memory allocated to ofdma might be a leakage when error occurs.
Signed-off-by: Cong Ding
---
drivers/of/dma.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 59631b2..583e50e3 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -107,6 +107,7 @@ int of_dma_controller_register(struct device_node *np,
if (!nbcells) {
pr_err("%s: #dma-cells property is missing or invalid\n",
__func__);
+ kfree(ofdma);
return -EINVAL;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kvm tools: remove redundant "if" condition
On Sat, Jan 19, 2013 at 10:58:33AM +0200, Pekka Enberg wrote:
> On Wed, Jan 16, 2013 at 6:52 PM, Cong Ding wrote:
> > After we check (state.kcount != 0), state.kcount has to be 0 in all the
> > "else"
> > branchs.
> >
> > Signed-off-by: Cong Ding
> > ---
> > tools/kvm/hw/i8042.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/kvm/hw/i8042.c b/tools/kvm/hw/i8042.c
> > index 9f8be6a..9035732 100644
> > --- a/tools/kvm/hw/i8042.c
> > +++ b/tools/kvm/hw/i8042.c
> > @@ -189,7 +189,7 @@ static u32 kbd_read_data(void)
> > state.mcount--;
> > kvm__irq_line(state.kvm, AUX_IRQ, 0);
> > kbd_update_irq();
> > - } else if (state.kcount == 0) {
> > + } else {
> > i = state.kread - 1;
> > if (i < 0)
> > i = QUEUE_SIZE;
>
> This doesn't look right. The 'kcount' field is an int so the value can
> be negative.
But the former check is "state.kcount != 0" as I described in the commit
message. Notice the difference between variable names in the "if" condition: the
first one is kcount, the second one is mcount, and the third one is same as the
first one kcount.
Ok, the original code is
if (state.kcount != 0) {
/* do something when (state.kcount != 0) */
} else if (state.mcount > 0) {
/* do something when (state.kcount == 0 && state.mount > 0) */
} else if (state.kcount == 0) {
/* do something when (state.kcount == 0 && state.mount <= 0) */
}
For the third branch, it runs when state.kcount == 0 and state.mount <= 0,
it's not necessary to ensure state.kcount == 0 again.
- cong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kvm tools: remove redundant if condition
On Sat, Jan 19, 2013 at 10:58:33AM +0200, Pekka Enberg wrote:
On Wed, Jan 16, 2013 at 6:52 PM, Cong Ding ding...@gmail.com wrote:
After we check (state.kcount != 0), state.kcount has to be 0 in all the
else
branchs.
Signed-off-by: Cong Ding ding...@gmail.com
---
tools/kvm/hw/i8042.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kvm/hw/i8042.c b/tools/kvm/hw/i8042.c
index 9f8be6a..9035732 100644
--- a/tools/kvm/hw/i8042.c
+++ b/tools/kvm/hw/i8042.c
@@ -189,7 +189,7 @@ static u32 kbd_read_data(void)
state.mcount--;
kvm__irq_line(state.kvm, AUX_IRQ, 0);
kbd_update_irq();
- } else if (state.kcount == 0) {
+ } else {
i = state.kread - 1;
if (i 0)
i = QUEUE_SIZE;
This doesn't look right. The 'kcount' field is an int so the value can
be negative.
But the former check is state.kcount != 0 as I described in the commit
message. Notice the difference between variable names in the if condition: the
first one is kcount, the second one is mcount, and the third one is same as the
first one kcount.
Ok, the original code is
if (state.kcount != 0) {
/* do something when (state.kcount != 0) */
} else if (state.mcount 0) {
/* do something when (state.kcount == 0 state.mount 0) */
} else if (state.kcount == 0) {
/* do something when (state.kcount == 0 state.mount = 0) */
}
For the third branch, it runs when state.kcount == 0 and state.mount = 0,
it's not necessary to ensure state.kcount == 0 again.
- cong
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: dma.c: fix memory leakage
The memory allocated to ofdma might be a leakage when error occurs.
Signed-off-by: Cong Ding ding...@gmail.com
---
drivers/of/dma.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 59631b2..583e50e3 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -107,6 +107,7 @@ int of_dma_controller_register(struct device_node *np,
if (!nbcells) {
pr_err(%s: #dma-cells property is missing or invalid\n,
__func__);
+ kfree(ofdma);
return -EINVAL;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] btrfs: fix potential null pointer dereference bug
The bug happens when rb_node == NULL. It causes variable node to be NULL and
then the NULL pointer is dereferenced this line:
BUG_ON((struct btrfs_root *)node-data != root);
Based on my analysis, function tree_search should not return NULL to variable
rb_node in this case (otherwise here has to be something unknown thing wrong),
so I replace if (rb_node) with UG_ON(!rb_node).
Signed-off-by: Cong Ding ding...@gmail.com
---
fs/btrfs/relocation.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 17c306b..d674671 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1263,10 +1263,11 @@ static int __update_reloc_root(struct btrfs_root *root,
int del)
spin_lock(rc-reloc_root_tree.lock);
rb_node = tree_search(rc-reloc_root_tree.rb_root,
root-commit_root-start);
- if (rb_node) {
- node = rb_entry(rb_node, struct mapping_node, rb_node);
- rb_erase(node-rb_node, rc-reloc_root_tree.rb_root);
- }
+ BUG_ON(!rb_node);
+
+ node = rb_entry(rb_node, struct mapping_node, rb_node);
+ rb_erase(node-rb_node, rc-reloc_root_tree.rb_root);
+
spin_unlock(rc-reloc_root_tree.lock);
BUG_ON((struct btrfs_root *)node-data != root);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: zcache-main: Fixed Camel Case Issue
On Fri, Jan 18, 2013 at 09:56:44PM -0500, Jake Champlin wrote:
> Fixed a camel case coding style issue.
>
> Signed-off-by: Jake Champlin
> ---
> drivers/staging/zcache/zcache-main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/zcache/zcache-main.c
> b/drivers/staging/zcache/zcache-main.c
> index 52b43b7..95be348 100644
> --- a/drivers/staging/zcache/zcache-main.c
> +++ b/drivers/staging/zcache/zcache-main.c
> @@ -1851,7 +1851,7 @@ static int zcache_frontswap_store(unsigned type,
> pgoff_t offset,
> int ret = -1;
> unsigned long flags;
>
> - BUG_ON(!PageLocked(page));
> + BUG_ON(!page_locked(page));
> if (likely(ind64 == ind)) {
> local_irq_save(flags);
> ret = zcache_put_page(LOCAL_CLIENT, zcache_frontswap_poolid,
> @@ -1871,7 +1871,7 @@ static int zcache_frontswap_load(unsigned type, pgoff_t
> offset,
> struct tmem_oid oid = oswiz(type, ind);
> int ret = -1;
>
> - BUG_ON(!PageLocked(page));
> + BUG_ON(!page_locked(page));
again, that doesn't work. Did you try to build the code?
- cong
> if (likely(ind64 == ind))
> ret = zcache_get_page(LOCAL_CLIENT, zcache_frontswap_poolid,
> , iswiz(ind), page);
> --
> 1.8.1.1
>
>
> --
> Jake Champlin
> jake.champlin...@gmail.com
> 8123742937
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] udf: add extent cache support in case of file reading
On Sat, Jan 19, 2013 at 11:17:14AM +0900, Namjae Jeon wrote:
> From: Namjae Jeon
>
> This patch implements extent caching in case of file reading.
> While reading a file, currently, UDF reads metadata serially
> which takes a lot of time depending on the number of extents present
> in the file. Caching last accessd extent improves metadata read time.
> Instead of reading file metadata from start, now we read from
> the cached extent.
>
> This patch considerably improves the time spent by CPU in kernel mode.
> For example, while reading a 10.9 GB file using dd:
> Time before applying patch:
> 11677022208 bytes (10.9GB) copied, 1529.748921 seconds, 7.3MB/s
> real25m 29.85s
> user0m 12.41s
> sys 15m 34.75s
>
> Time after applying patch:
> 11677022208 bytes (10.9GB) copied, 1469.338231 seconds, 7.6MB/s
> real24m 29.44s
> user0m 15.73s
> sys 3m 27.61s
did you have any test on lots of small files?
- cong
>
> Signed-off-by: Namjae Jeon
> Signed-off-by: Ashish Sangwan
> Signed-off-by: Bonggil Bak
> ---
> fs/udf/ialloc.c |4 +++
> fs/udf/inode.c | 79
> +-
> fs/udf/udf_i.h | 16 +++
> fs/udf/udfdecl.h | 10 +++
> 4 files changed, 98 insertions(+), 11 deletions(-)
>
> diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
> index 7e5aae4..0cb208e 100644
> --- a/fs/udf/ialloc.c
> +++ b/fs/udf/ialloc.c
> @@ -117,6 +117,10 @@ struct inode *udf_new_inode(struct inode *dir, umode_t
> mode, int *err)
> iinfo->i_lenAlloc = 0;
> iinfo->i_use = 0;
> iinfo->i_checkpoint = 1;
> + memset(>cached_extent, 0, sizeof(struct udf_ext_cache));
> + spin_lock_init(&(iinfo->i_extent_cache_lock));
> + /* Mark extent cache as invalid for now */
> + iinfo->cached_extent.lstart = -1;
> if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_AD_IN_ICB))
> iinfo->i_alloc_type = ICBTAG_FLAG_AD_IN_ICB;
> else if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_SHORT_AD))
> diff --git a/fs/udf/inode.c b/fs/udf/inode.c
> index e78ef48..86e0469 100644
> --- a/fs/udf/inode.c
> +++ b/fs/udf/inode.c
> @@ -91,6 +91,7 @@ void udf_evict_inode(struct inode *inode)
> }
> kfree(iinfo->i_ext.i_data);
> iinfo->i_ext.i_data = NULL;
> + udf_clear_extent_cache(iinfo);
> if (want_delete) {
> udf_free_inode(inode);
> }
> @@ -106,6 +107,7 @@ static void udf_write_failed(struct address_space
> *mapping, loff_t to)
> truncate_pagecache(inode, to, isize);
> if (iinfo->i_alloc_type != ICBTAG_FLAG_AD_IN_ICB) {
> down_write(>i_data_sem);
> + udf_clear_extent_cache(iinfo);
> udf_truncate_extents(inode);
> up_write(>i_data_sem);
> }
> @@ -373,7 +375,7 @@ static int udf_get_block(struct inode *inode, sector_t
> block,
> iinfo->i_next_alloc_goal++;
> }
>
> -
> + udf_clear_extent_cache(iinfo);
> phys = inode_getblk(inode, block, , );
> if (!phys)
> goto abort;
> @@ -1172,6 +1174,7 @@ set_size:
> } else {
> if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
> down_write(>i_data_sem);
> + udf_clear_extent_cache(iinfo);
> memset(iinfo->i_ext.i_data + iinfo->i_lenEAttr +
> newsize,
> 0x00, bsize - newsize -
> udf_file_entry_alloc_offset(inode));
> @@ -1185,6 +1188,7 @@ set_size:
> if (err)
> return err;
> down_write(>i_data_sem);
> + udf_clear_extent_cache(iinfo);
> truncate_setsize(inode, newsize);
> udf_truncate_extents(inode);
> up_write(>i_data_sem);
> @@ -1302,6 +1306,9 @@ static void udf_fill_inode(struct inode *inode, struct
> buffer_head *bh)
> iinfo->i_lenAlloc = 0;
> iinfo->i_next_alloc_block = 0;
> iinfo->i_next_alloc_goal = 0;
> + memset(>cached_extent, 0, sizeof(struct udf_ext_cache));
> + spin_lock_init(&(iinfo->i_extent_cache_lock));
> + iinfo->cached_extent.lstart = -1;
> if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_EFE)) {
> iinfo->i_efe = 1;
> iinfo->i_use = 0;
> @@ -2157,11 +2164,12 @@ int8_t inode_bmap(struct inode *inode, sector_t block,
> struct udf_inode_info *iinfo;
>
> iinfo = UDF_I(inode);
> - pos->offset = 0;
> - pos->block = iinfo->i_location;
> - pos->bh = NULL;
> + if (!udf_read_extent_cache(inode, bcount, , pos)) {
> + pos->offset = 0;
> + pos->block = iinfo->i_location;
> + pos->bh = NULL;
> + }
> *elen = 0;
> -
> do {
> etype = udf_next_aext(inode, pos, eloc, elen, 1);
> if (etype == -1) {
> @@ -2171,7 +2179,8 @@ int8_t inode_bmap(struct inode *inode,
[PATCH] include/keys/system_keyring.h: fix building error
When I am doing "make randconfig", it causes the following building error if CONFIG_SYSTEM_TRUSTED_KEYRING is not defined and CONFIG_MODULE_SIG is defined. kernel/module_signing.c: In function ‘request_asymmetric_key’: kernel/module_signing.c:161:36: error: ‘system_trusted_keyring’ undeclared (first use in this function) kernel/module_signing.c:161:36: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: Cong Ding --- include/keys/system_keyring.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h index 8dabc39..d66c92d 100644 --- a/include/keys/system_keyring.h +++ b/include/keys/system_keyring.h @@ -12,7 +12,7 @@ #ifndef _KEYS_SYSTEM_KEYRING_H #define _KEYS_SYSTEM_KEYRING_H -#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING +#if defined(CONFIG_SYSTEM_TRUSTED_KEYRING) || defined(CONFIG_MODULE_SIG) #include -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs: timerfd.c: fix build error
Invalid number of parentheses if macro COMPAT is defined Signed-off-by: Cong Ding --- fs/timerfd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/timerfd.c b/fs/timerfd.c index 14ad4f3..0e606b1 100644 --- a/fs/timerfd.c +++ b/fs/timerfd.c @@ -396,7 +396,7 @@ COMPAT_SYSCALL_DEFINE4(timerfd_settime, int, ufd, int, flags, ret = do_timerfd_settime(ufd, flags, , ); if (ret) return ret; - if (otmr && put_compat_itimerspec(otmr, ) + if (otmr && put_compat_itimerspec(otmr, )) return -EFAULT; return ret; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch wrote:
> On Thu, Nov 29, 2012 at 05:40:00PM +0000, Cong Ding wrote:
>> In version 1, I forgot to modify the same bug in the first loop.
>>
>> we have to call kobject_put() to clean up the kobject after function
>> kobject_init(), kobject_add(), or kobject_uevent() is called.
>>
>> Signed-off-by: Cong Ding
>
> Signed-off-by: "Hans J. Koch"
Hi Greg, is this patch stil in the queue?
- cong
>> ---
>> drivers/uio/uio.c | 16 ++--
>> 1 files changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index 5110f36..79774d3 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -291,10 +291,10 @@ static int uio_dev_add_attributes(struct uio_device
>> *idev)
>> mem->map = map;
>> ret = kobject_add(>kobj, idev->map_dir, "map%d", mi);
>> if (ret)
>> - goto err_map;
>> + goto err_map_kobj;
>> ret = kobject_uevent(>kobj, KOBJ_ADD);
>> if (ret)
>> - goto err_map;
>> + goto err_map_kobj;
>> }
>>
>> for (pi = 0; pi < MAX_UIO_PORT_REGIONS; pi++) {
>> @@ -317,23 +317,27 @@ static int uio_dev_add_attributes(struct uio_device
>> *idev)
>> ret = kobject_add(>kobj, idev->portio_dir,
>> "port%d", pi);
>> if (ret)
>> - goto err_portio;
>> + goto err_portio_kobj;
>> ret = kobject_uevent(>kobj, KOBJ_ADD);
>> if (ret)
>> - goto err_portio;
>> + goto err_portio_kobj;
>> }
>>
>> return 0;
>>
>> err_portio:
>> - for (pi--; pi >= 0; pi--) {
>> + pi--;
>> +err_portio_kobj:
>> + for (; pi >= 0; pi--) {
>> port = >info->port[pi];
>> portio = port->portio;
>> kobject_put(>kobj);
>> }
>> kobject_put(idev->portio_dir);
>> err_map:
>> - for (mi--; mi>=0; mi--) {
>> + mi--;
>> +err_map_kobj:
>> + for (; mi >= 0; mi--) {
>> mem = >info->mem[mi];
>> map = mem->map;
>> kobject_put(>kobj);
>> --
>> 1.7.4.5
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi:gdth.c: fix compilation warning
Hi all, is this still in the queue or...?
- cong
On Mon, Dec 3, 2012 at 11:19 AM, Cong Ding wrote:
> We do not allow old-style function definition. Always spell foo(void) if
> a function does not take any parameters.
>
> Signed-off-by: Cong Ding
> ---
> drivers/scsi/gdth.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
> index 5d72274..950c095 100644
> --- a/drivers/scsi/gdth.c
> +++ b/drivers/scsi/gdth.c
> @@ -204,7 +204,7 @@ static char strbuf[MAX_SERBUF+1];
> #else
> #define COM_BASE 0x3f8
> #endif
> -static void ser_init()
> +static void ser_init(void)
> {
> unsigned port=COM_BASE;
>
> --
> 1.7.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix compilation warning
Is this patch still queued or...? - cong On Wed, Dec 5, 2012 at 6:10 PM, Cong Ding wrote: > the following compilation warning is caused by Commit-ID: > c566e8e9e44b72b53091da20e2dedefc730f2ee2 > > kernel/sched/debug.c: In function ‘print_cfs_rq’: > kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type > ‘long int’, but argument 4 has type ‘long long int’ [-Wformat] > kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type > ‘long int’, but argument 3 has type ‘long long int’ [-Wformat] > > where function atomic64_read returns long long int, but %ld was used in the > printf > > Signed-off-by: Cong Ding > --- > kernel/sched/debug.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c > index 2cd3c1b..83ec463 100644 > --- a/kernel/sched/debug.c > +++ b/kernel/sched/debug.c > @@ -222,7 +222,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct > cfs_rq *cfs_rq) > cfs_rq->runnable_load_avg); > SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg", > cfs_rq->blocked_load_avg); > - SEQ_printf(m, " .%-30s: %ld\n", "tg_load_avg", > + SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg", > atomic64_read(_rq->tg->load_avg)); > SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib", > cfs_rq->tg_load_contrib); > -- > 1.7.4.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iommu: omap-iommu.c: remove unnecessary null pointer check
The pointer obj is dereferenced in line 146 and 149 respectively, so it is not necessary to check null again in line 149 and 175. And I have checked that all the callers of these two functions guarantee the parameter obj passed is not null. Signed-off-by: Cong Ding --- drivers/iommu/omap-iommu.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index d33c980..6ac02fa 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -146,7 +146,7 @@ static int iommu_enable(struct omap_iommu *obj) struct platform_device *pdev = to_platform_device(obj->dev); struct iommu_platform_data *pdata = pdev->dev.platform_data; - if (!obj || !pdata) + if (!pdata) return -EINVAL; if (!arch_iommu) @@ -172,7 +172,7 @@ static void iommu_disable(struct omap_iommu *obj) struct platform_device *pdev = to_platform_device(obj->dev); struct iommu_platform_data *pdata = pdev->dev.platform_data; - if (!obj || !pdata) + if (!pdata) return; arch_iommu->disable(obj); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iommu: omap-iommu.c: remove unnecessary null pointer check
The pointer obj is dereferenced in line 146 and 149 respectively, so it is not necessary to check null again in line 149 and 175. And I have checked that all the callers of these two functions guarantee the parameter obj passed is not null. Signed-off-by: Cong Ding ding...@gmail.com --- drivers/iommu/omap-iommu.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index d33c980..6ac02fa 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -146,7 +146,7 @@ static int iommu_enable(struct omap_iommu *obj) struct platform_device *pdev = to_platform_device(obj-dev); struct iommu_platform_data *pdata = pdev-dev.platform_data; - if (!obj || !pdata) + if (!pdata) return -EINVAL; if (!arch_iommu) @@ -172,7 +172,7 @@ static void iommu_disable(struct omap_iommu *obj) struct platform_device *pdev = to_platform_device(obj-dev); struct iommu_platform_data *pdata = pdev-dev.platform_data; - if (!obj || !pdata) + if (!pdata) return; arch_iommu-disable(obj); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix compilation warning
Is this patch still queued or...? - cong On Wed, Dec 5, 2012 at 6:10 PM, Cong Ding ding...@gmail.com wrote: the following compilation warning is caused by Commit-ID: c566e8e9e44b72b53091da20e2dedefc730f2ee2 kernel/sched/debug.c: In function ‘print_cfs_rq’: kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long int’ [-Wformat] kernel/sched/debug.c:225:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat] where function atomic64_read returns long long int, but %ld was used in the printf Signed-off-by: Cong Ding ding...@gmail.com --- kernel/sched/debug.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index 2cd3c1b..83ec463 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -222,7 +222,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq) cfs_rq-runnable_load_avg); SEQ_printf(m, .%-30s: %lld\n, blocked_load_avg, cfs_rq-blocked_load_avg); - SEQ_printf(m, .%-30s: %ld\n, tg_load_avg, + SEQ_printf(m, .%-30s: %lld\n, tg_load_avg, atomic64_read(cfs_rq-tg-load_avg)); SEQ_printf(m, .%-30s: %lld\n, tg_load_contrib, cfs_rq-tg_load_contrib); -- 1.7.4.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi:gdth.c: fix compilation warning
Hi all, is this still in the queue or...?
- cong
On Mon, Dec 3, 2012 at 11:19 AM, Cong Ding ding...@gmail.com wrote:
We do not allow old-style function definition. Always spell foo(void) if
a function does not take any parameters.
Signed-off-by: Cong Ding ding...@gmail.com
---
drivers/scsi/gdth.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 5d72274..950c095 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -204,7 +204,7 @@ static char strbuf[MAX_SERBUF+1];
#else
#define COM_BASE 0x3f8
#endif
-static void ser_init()
+static void ser_init(void)
{
unsigned port=COM_BASE;
--
1.7.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] uio.c: solve memory leak
On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch h...@hansjkoch.de wrote:
On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote:
In version 1, I forgot to modify the same bug in the first loop.
we have to call kobject_put() to clean up the kobject after function
kobject_init(), kobject_add(), or kobject_uevent() is called.
Signed-off-by: Cong Ding ding...@gmail.com
Signed-off-by: Hans J. Koch h...@hansjkoch.de
Hi Greg, is this patch stil in the queue?
- cong
---
drivers/uio/uio.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5110f36..79774d3 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -291,10 +291,10 @@ static int uio_dev_add_attributes(struct uio_device
*idev)
mem-map = map;
ret = kobject_add(map-kobj, idev-map_dir, map%d, mi);
if (ret)
- goto err_map;
+ goto err_map_kobj;
ret = kobject_uevent(map-kobj, KOBJ_ADD);
if (ret)
- goto err_map;
+ goto err_map_kobj;
}
for (pi = 0; pi MAX_UIO_PORT_REGIONS; pi++) {
@@ -317,23 +317,27 @@ static int uio_dev_add_attributes(struct uio_device
*idev)
ret = kobject_add(portio-kobj, idev-portio_dir,
port%d, pi);
if (ret)
- goto err_portio;
+ goto err_portio_kobj;
ret = kobject_uevent(portio-kobj, KOBJ_ADD);
if (ret)
- goto err_portio;
+ goto err_portio_kobj;
}
return 0;
err_portio:
- for (pi--; pi = 0; pi--) {
+ pi--;
+err_portio_kobj:
+ for (; pi = 0; pi--) {
port = idev-info-port[pi];
portio = port-portio;
kobject_put(portio-kobj);
}
kobject_put(idev-portio_dir);
err_map:
- for (mi--; mi=0; mi--) {
+ mi--;
+err_map_kobj:
+ for (; mi = 0; mi--) {
mem = idev-info-mem[mi];
map = mem-map;
kobject_put(map-kobj);
--
1.7.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs: timerfd.c: fix build error
Invalid number of parentheses if macro COMPAT is defined Signed-off-by: Cong Ding ding...@gmail.com --- fs/timerfd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/timerfd.c b/fs/timerfd.c index 14ad4f3..0e606b1 100644 --- a/fs/timerfd.c +++ b/fs/timerfd.c @@ -396,7 +396,7 @@ COMPAT_SYSCALL_DEFINE4(timerfd_settime, int, ufd, int, flags, ret = do_timerfd_settime(ufd, flags, new, old); if (ret) return ret; - if (otmr put_compat_itimerspec(otmr, old) + if (otmr put_compat_itimerspec(otmr, old)) return -EFAULT; return ret; } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] include/keys/system_keyring.h: fix building error
When I am doing make randconfig, it causes the following building error if CONFIG_SYSTEM_TRUSTED_KEYRING is not defined and CONFIG_MODULE_SIG is defined. kernel/module_signing.c: In function ‘request_asymmetric_key’: kernel/module_signing.c:161:36: error: ‘system_trusted_keyring’ undeclared (first use in this function) kernel/module_signing.c:161:36: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: Cong Ding ding...@gmail.com --- include/keys/system_keyring.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h index 8dabc39..d66c92d 100644 --- a/include/keys/system_keyring.h +++ b/include/keys/system_keyring.h @@ -12,7 +12,7 @@ #ifndef _KEYS_SYSTEM_KEYRING_H #define _KEYS_SYSTEM_KEYRING_H -#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING +#if defined(CONFIG_SYSTEM_TRUSTED_KEYRING) || defined(CONFIG_MODULE_SIG) #include linux/key.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] udf: add extent cache support in case of file reading
On Sat, Jan 19, 2013 at 11:17:14AM +0900, Namjae Jeon wrote:
From: Namjae Jeon namjae.j...@samsung.com
This patch implements extent caching in case of file reading.
While reading a file, currently, UDF reads metadata serially
which takes a lot of time depending on the number of extents present
in the file. Caching last accessd extent improves metadata read time.
Instead of reading file metadata from start, now we read from
the cached extent.
This patch considerably improves the time spent by CPU in kernel mode.
For example, while reading a 10.9 GB file using dd:
Time before applying patch:
11677022208 bytes (10.9GB) copied, 1529.748921 seconds, 7.3MB/s
real25m 29.85s
user0m 12.41s
sys 15m 34.75s
Time after applying patch:
11677022208 bytes (10.9GB) copied, 1469.338231 seconds, 7.6MB/s
real24m 29.44s
user0m 15.73s
sys 3m 27.61s
did you have any test on lots of small files?
- cong
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
Signed-off-by: Bonggil Bak bg...@samsung.com
---
fs/udf/ialloc.c |4 +++
fs/udf/inode.c | 79
+-
fs/udf/udf_i.h | 16 +++
fs/udf/udfdecl.h | 10 +++
4 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
index 7e5aae4..0cb208e 100644
--- a/fs/udf/ialloc.c
+++ b/fs/udf/ialloc.c
@@ -117,6 +117,10 @@ struct inode *udf_new_inode(struct inode *dir, umode_t
mode, int *err)
iinfo-i_lenAlloc = 0;
iinfo-i_use = 0;
iinfo-i_checkpoint = 1;
+ memset(iinfo-cached_extent, 0, sizeof(struct udf_ext_cache));
+ spin_lock_init((iinfo-i_extent_cache_lock));
+ /* Mark extent cache as invalid for now */
+ iinfo-cached_extent.lstart = -1;
if (UDF_QUERY_FLAG(inode-i_sb, UDF_FLAG_USE_AD_IN_ICB))
iinfo-i_alloc_type = ICBTAG_FLAG_AD_IN_ICB;
else if (UDF_QUERY_FLAG(inode-i_sb, UDF_FLAG_USE_SHORT_AD))
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index e78ef48..86e0469 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -91,6 +91,7 @@ void udf_evict_inode(struct inode *inode)
}
kfree(iinfo-i_ext.i_data);
iinfo-i_ext.i_data = NULL;
+ udf_clear_extent_cache(iinfo);
if (want_delete) {
udf_free_inode(inode);
}
@@ -106,6 +107,7 @@ static void udf_write_failed(struct address_space
*mapping, loff_t to)
truncate_pagecache(inode, to, isize);
if (iinfo-i_alloc_type != ICBTAG_FLAG_AD_IN_ICB) {
down_write(iinfo-i_data_sem);
+ udf_clear_extent_cache(iinfo);
udf_truncate_extents(inode);
up_write(iinfo-i_data_sem);
}
@@ -373,7 +375,7 @@ static int udf_get_block(struct inode *inode, sector_t
block,
iinfo-i_next_alloc_goal++;
}
-
+ udf_clear_extent_cache(iinfo);
phys = inode_getblk(inode, block, err, new);
if (!phys)
goto abort;
@@ -1172,6 +1174,7 @@ set_size:
} else {
if (iinfo-i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
down_write(iinfo-i_data_sem);
+ udf_clear_extent_cache(iinfo);
memset(iinfo-i_ext.i_data + iinfo-i_lenEAttr +
newsize,
0x00, bsize - newsize -
udf_file_entry_alloc_offset(inode));
@@ -1185,6 +1188,7 @@ set_size:
if (err)
return err;
down_write(iinfo-i_data_sem);
+ udf_clear_extent_cache(iinfo);
truncate_setsize(inode, newsize);
udf_truncate_extents(inode);
up_write(iinfo-i_data_sem);
@@ -1302,6 +1306,9 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
iinfo-i_lenAlloc = 0;
iinfo-i_next_alloc_block = 0;
iinfo-i_next_alloc_goal = 0;
+ memset(iinfo-cached_extent, 0, sizeof(struct udf_ext_cache));
+ spin_lock_init((iinfo-i_extent_cache_lock));
+ iinfo-cached_extent.lstart = -1;
if (fe-descTag.tagIdent == cpu_to_le16(TAG_IDENT_EFE)) {
iinfo-i_efe = 1;
iinfo-i_use = 0;
@@ -2157,11 +2164,12 @@ int8_t inode_bmap(struct inode *inode, sector_t block,
struct udf_inode_info *iinfo;
iinfo = UDF_I(inode);
- pos-offset = 0;
- pos-block = iinfo-i_location;
- pos-bh = NULL;
+ if (!udf_read_extent_cache(inode, bcount, lbcount, pos)) {
+ pos-offset = 0;
+ pos-block = iinfo-i_location;
+ pos-bh = NULL;
+ }
*elen = 0;
-
do {
etype = udf_next_aext(inode, pos, eloc, elen, 1);
if (etype == -1) {
@@ -2171,7 +2179,8 @@ int8_t inode_bmap(struct inode *inode, sector_t block,
Re: [PATCH] Staging: zcache-main: Fixed Camel Case Issue
On Fri, Jan 18, 2013 at 09:56:44PM -0500, Jake Champlin wrote:
Fixed a camel case coding style issue.
Signed-off-by: Jake Champlin jake.champlin...@gmail.com
---
drivers/staging/zcache/zcache-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/zcache/zcache-main.c
b/drivers/staging/zcache/zcache-main.c
index 52b43b7..95be348 100644
--- a/drivers/staging/zcache/zcache-main.c
+++ b/drivers/staging/zcache/zcache-main.c
@@ -1851,7 +1851,7 @@ static int zcache_frontswap_store(unsigned type,
pgoff_t offset,
int ret = -1;
unsigned long flags;
- BUG_ON(!PageLocked(page));
+ BUG_ON(!page_locked(page));
if (likely(ind64 == ind)) {
local_irq_save(flags);
ret = zcache_put_page(LOCAL_CLIENT, zcache_frontswap_poolid,
@@ -1871,7 +1871,7 @@ static int zcache_frontswap_load(unsigned type, pgoff_t
offset,
struct tmem_oid oid = oswiz(type, ind);
int ret = -1;
- BUG_ON(!PageLocked(page));
+ BUG_ON(!page_locked(page));
again, that doesn't work. Did you try to build the code?
- cong
if (likely(ind64 == ind))
ret = zcache_get_page(LOCAL_CLIENT, zcache_frontswap_poolid,
oid, iswiz(ind), page);
--
1.8.1.1
--
Jake Champlin
jake.champlin...@gmail.com
8123742937
MuttClient
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] sparc: kernel/sbus.c: fix memory leakage
The variable iommu and strbuf are not freed properly if it goes to error.
Signed-off-by: Cong Ding
---
arch/sparc/kernel/sbus.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c
index 1271b3a..be5bdf9 100644
--- a/arch/sparc/kernel/sbus.c
+++ b/arch/sparc/kernel/sbus.c
@@ -554,10 +554,8 @@ static void __init sbus_iommu_init(struct platform_device
*op)
regs = pr->phys_addr;
iommu = kzalloc(sizeof(*iommu), GFP_ATOMIC);
- if (!iommu)
- goto fatal_memory_error;
strbuf = kzalloc(sizeof(*strbuf), GFP_ATOMIC);
- if (!strbuf)
+ if (!iommu || !strbuf)
goto fatal_memory_error;
op->dev.archdata.iommu = iommu;
@@ -656,6 +654,8 @@ static void __init sbus_iommu_init(struct platform_device
*op)
return;
fatal_memory_error:
+ kfree(iommu);
+ kfree(strbuf);
prom_printf("sbus_iommu_init: Fatal memory allocation error.\n");
}
--
1.7.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sparc: kernel/sbus.c: fix memory leakage
On Thu, Jan 17, 2013 at 12:30:11PM +, Richard Mortimer wrote: > > > On 17/01/2013 11:56, Cong Ding wrote: > >On Thu, Jan 17, 2013 at 10:41:59AM +, Richard Mortimer wrote: > >> > >> > >>On 16/01/2013 22:01, Cong Ding wrote: > >>>the variable iommu and strbuf are not freed if it goes to error. > >>> > >>>Signed-off-by: Cong Ding > >>>--- > >>> arch/sparc/kernel/sbus.c |2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>>diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c > >>>index 1271b3a..78aa26b 100644 > >>>--- a/arch/sparc/kernel/sbus.c > >>>+++ b/arch/sparc/kernel/sbus.c > >>>@@ -656,6 +656,8 @@ static void __init sbus_iommu_init(struct > >>>platform_device *op) > >>> return; > >>> > >>> fatal_memory_error: > >>>+ kfree(strbuf); > >> > >>strbuf will be uninitialized if the iommu allocation fails. I don't > >>have a particular preference for how to fix this but tend to dislike > >>initial assignment with NULL because it hides other control flow > >>issues. > >Sorry I didn't notice strbuf will be uninitialized here. But if we don't > >initially assign a NULL value to strbuf, I cannot find a way to handle it > >besides the first version patch. Did you have any suggestions? For me, I like > >the first version. > > Two thoughts... > > 1 - just use a goto target for the iommu allocation failure and make > that skip the strbuf free call. The others use the existing > fatal_memory_error label. this looks ugly. If we do in this way, why not version 1? > > 2 - Move the strbuf kzalloc up 2 lines so that it occurs before the > test for iommu. > > 2b - In case (2) above the failure test could be changed to > if (!iommu || !strbuf) > to remove duplication of goto. I will send a new version by using this solution. Thanks, - cong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sparc: kernel/sbus.c: fix memory leakage
On Thu, Jan 17, 2013 at 10:41:59AM +, Richard Mortimer wrote:
>
>
> On 16/01/2013 22:01, Cong Ding wrote:
> >the variable iommu and strbuf are not freed if it goes to error.
> >
> >Signed-off-by: Cong Ding
> >---
> > arch/sparc/kernel/sbus.c |2 ++
> > 1 file changed, 2 insertions(+)
> >
> >diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c
> >index 1271b3a..78aa26b 100644
> >--- a/arch/sparc/kernel/sbus.c
> >+++ b/arch/sparc/kernel/sbus.c
> >@@ -656,6 +656,8 @@ static void __init sbus_iommu_init(struct
> >platform_device *op)
> > return;
> >
> > fatal_memory_error:
> >+kfree(strbuf);
>
> strbuf will be uninitialized if the iommu allocation fails. I don't
> have a particular preference for how to fix this but tend to dislike
> initial assignment with NULL because it hides other control flow
> issues.
Sorry I didn't notice strbuf will be uninitialized here. But if we don't
initially assign a NULL value to strbuf, I cannot find a way to handle it
besides the first version patch. Did you have any suggestions? For me, I like
the first version.
- cong
>
> Regards
>
> Richard
>
> >+kfree(iommu);
> > prom_printf("sbus_iommu_init: Fatal memory allocation error.\n");
> > }
> >
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sparc: kernel/sbus.c: fix memory leakage
On Thu, Jan 17, 2013 at 10:41:59AM +, Richard Mortimer wrote: On 16/01/2013 22:01, Cong Ding wrote: the variable iommu and strbuf are not freed if it goes to error. Signed-off-by: Cong Ding ding...@gmail.com --- arch/sparc/kernel/sbus.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c index 1271b3a..78aa26b 100644 --- a/arch/sparc/kernel/sbus.c +++ b/arch/sparc/kernel/sbus.c @@ -656,6 +656,8 @@ static void __init sbus_iommu_init(struct platform_device *op) return; fatal_memory_error: +kfree(strbuf); strbuf will be uninitialized if the iommu allocation fails. I don't have a particular preference for how to fix this but tend to dislike initial assignment with NULL because it hides other control flow issues. Sorry I didn't notice strbuf will be uninitialized here. But if we don't initially assign a NULL value to strbuf, I cannot find a way to handle it besides the first version patch. Did you have any suggestions? For me, I like the first version. - cong Regards Richard +kfree(iommu); prom_printf(sbus_iommu_init: Fatal memory allocation error.\n); } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sparc: kernel/sbus.c: fix memory leakage
On Thu, Jan 17, 2013 at 12:30:11PM +, Richard Mortimer wrote: On 17/01/2013 11:56, Cong Ding wrote: On Thu, Jan 17, 2013 at 10:41:59AM +, Richard Mortimer wrote: On 16/01/2013 22:01, Cong Ding wrote: the variable iommu and strbuf are not freed if it goes to error. Signed-off-by: Cong Ding ding...@gmail.com --- arch/sparc/kernel/sbus.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c index 1271b3a..78aa26b 100644 --- a/arch/sparc/kernel/sbus.c +++ b/arch/sparc/kernel/sbus.c @@ -656,6 +656,8 @@ static void __init sbus_iommu_init(struct platform_device *op) return; fatal_memory_error: + kfree(strbuf); strbuf will be uninitialized if the iommu allocation fails. I don't have a particular preference for how to fix this but tend to dislike initial assignment with NULL because it hides other control flow issues. Sorry I didn't notice strbuf will be uninitialized here. But if we don't initially assign a NULL value to strbuf, I cannot find a way to handle it besides the first version patch. Did you have any suggestions? For me, I like the first version. Two thoughts... 1 - just use a goto target for the iommu allocation failure and make that skip the strbuf free call. The others use the existing fatal_memory_error label. this looks ugly. If we do in this way, why not version 1? 2 - Move the strbuf kzalloc up 2 lines so that it occurs before the test for iommu. 2b - In case (2) above the failure test could be changed to if (!iommu || !strbuf) to remove duplication of goto. I will send a new version by using this solution. Thanks, - cong -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] sparc: kernel/sbus.c: fix memory leakage
The variable iommu and strbuf are not freed properly if it goes to error. Signed-off-by: Cong Ding ding...@gmail.com --- arch/sparc/kernel/sbus.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c index 1271b3a..be5bdf9 100644 --- a/arch/sparc/kernel/sbus.c +++ b/arch/sparc/kernel/sbus.c @@ -554,10 +554,8 @@ static void __init sbus_iommu_init(struct platform_device *op) regs = pr-phys_addr; iommu = kzalloc(sizeof(*iommu), GFP_ATOMIC); - if (!iommu) - goto fatal_memory_error; strbuf = kzalloc(sizeof(*strbuf), GFP_ATOMIC); - if (!strbuf) + if (!iommu || !strbuf) goto fatal_memory_error; op-dev.archdata.iommu = iommu; @@ -656,6 +654,8 @@ static void __init sbus_iommu_init(struct platform_device *op) return; fatal_memory_error: + kfree(iommu); + kfree(strbuf); prom_printf(sbus_iommu_init: Fatal memory allocation error.\n); } -- 1.7.4.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: serial/68328serial.c: remove unnecessary null pointer check
The pointer info is dereferened in line 1009, so it is not necessary to check null again in line 1012. Signed-off-by: Cong Ding --- drivers/tty/serial/68328serial.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/68328serial.c b/drivers/tty/serial/68328serial.c index f99a845..4f7c0d2 100644 --- a/drivers/tty/serial/68328serial.c +++ b/drivers/tty/serial/68328serial.c @@ -1009,7 +1009,7 @@ static void rs_close(struct tty_struct *tty, struct file * filp) m68328_uart *uart = _addr[info->line]; unsigned long flags; - if (!info || serial_paranoia_check(info, tty->name, "rs_close")) + if (serial_paranoia_check(info, tty->name, "rs_close")) return; local_irq_save(flags); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: serial/vt8500_serial.c: fix bug caused by missing "{}"
It is obviously here should be braced by "{}" in the "if" branch (more than 1
line in the "if" branch), and by the
coding style document of the kernel I also add "{}" to the else branch.
Signed-off-by: Cong Ding
---
drivers/tty/serial/vt8500_serial.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 8fd1814..ac46a6e 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -567,12 +567,13 @@ static int vt8500_serial_probe(struct platform_device
*pdev)
if (!mmres || !irqres)
return -ENODEV;
- if (np)
+ if (np) {
port = of_alias_get_id(np, "serial");
if (port > VT8500_MAX_PORTS)
port = -1;
- else
+ } else {
port = -1;
+ }
if (port < 0) {
/* calculate the port id */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] sparc: kernel/sbus.c: fix memory leakage
the variable iommu and strbuf are not freed if it goes to error.
Signed-off-by: Cong Ding
---
arch/sparc/kernel/sbus.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c
index 1271b3a..78aa26b 100644
--- a/arch/sparc/kernel/sbus.c
+++ b/arch/sparc/kernel/sbus.c
@@ -656,6 +656,8 @@ static void __init sbus_iommu_init(struct platform_device
*op)
return;
fatal_memory_error:
+ kfree(strbuf);
+ kfree(iommu);
prom_printf("sbus_iommu_init: Fatal memory allocation error.\n");
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sparc: kernel/sbus.c: fix memory leakage
On Wed, Jan 16, 2013 at 10:13:09PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 14, 2013 at 10:36:08PM +0100, Cong Ding wrote:
> > the variable iommu and strbuf are not freed if it goes to error.
> >
> > Signed-off-by: Cong Ding
> > ---
> > arch/sparc/kernel/sbus.c |8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c
> > index 1271b3a..0b66e53 100644
> > --- a/arch/sparc/kernel/sbus.c
> > +++ b/arch/sparc/kernel/sbus.c
> > @@ -555,10 +555,10 @@ static void __init sbus_iommu_init(struct
> > platform_device *op)
> >
> > iommu = kzalloc(sizeof(*iommu), GFP_ATOMIC);
> > if (!iommu)
> > - goto fatal_memory_error;
> > + goto fatal_iommu_memory_error;
> > strbuf = kzalloc(sizeof(*strbuf), GFP_ATOMIC);
> > if (!strbuf)
> > - goto fatal_memory_error;
> > + goto fatal_strbuf_memory_error;
> >
> > op->dev.archdata.iommu = iommu;
> > op->dev.archdata.stc = strbuf;
> > @@ -656,6 +656,10 @@ static void __init sbus_iommu_init(struct
> > platform_device *op)
> > return;
> >
> > fatal_memory_error:
> > + kfree(strbuf);
> > +fatal_strbuf_memory_error:
> > + kfree(iommu);
> > +fatal_iommu_memory_error:
> > prom_printf("sbus_iommu_init: Fatal memory allocation error.\n");
> > }
> kfree is a noop if passed a null pointer.
> So you can just add the missing kfree's to fix this.
>
> Sam
as far as I know, most codes in the kernel are in the same style as this
patch, but if you really prefer to do in the way you described I can send
a new version.
Let me know.
- cong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] kvm tools: close opened file
The file should be closed before return. Signed-off-by: Cong Ding --- tools/kvm/builtin-setup.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/kvm/builtin-setup.c b/tools/kvm/builtin-setup.c index c5b0566..8b45c56 100644 --- a/tools/kvm/builtin-setup.c +++ b/tools/kvm/builtin-setup.c @@ -159,12 +159,12 @@ static int copy_passwd(const char *guestfs_name) return -1; ret = fprintf(file, "root:x:0:0:root:/root:/bin/sh\n"); - if (ret < 0) - return ret; + if (ret > 0) + ret = 0; fclose(file); - return 0; + return ret; } static int make_guestfs_symlink(const char *guestfs_name, const char *path) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] kvm tools: remove redundant "if" condition
After we check (state.kcount != 0), state.kcount has to be 0 in all the "else"
branchs.
Signed-off-by: Cong Ding
---
tools/kvm/hw/i8042.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kvm/hw/i8042.c b/tools/kvm/hw/i8042.c
index 9f8be6a..9035732 100644
--- a/tools/kvm/hw/i8042.c
+++ b/tools/kvm/hw/i8042.c
@@ -189,7 +189,7 @@ static u32 kbd_read_data(void)
state.mcount--;
kvm__irq_line(state.kvm, AUX_IRQ, 0);
kbd_update_irq();
- } else if (state.kcount == 0) {
+ } else {
i = state.kread - 1;
if (i < 0)
i = QUEUE_SIZE;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] kvm tools: remove redundant if condition
After we check (state.kcount != 0), state.kcount has to be 0 in all the else
branchs.
Signed-off-by: Cong Ding ding...@gmail.com
---
tools/kvm/hw/i8042.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kvm/hw/i8042.c b/tools/kvm/hw/i8042.c
index 9f8be6a..9035732 100644
--- a/tools/kvm/hw/i8042.c
+++ b/tools/kvm/hw/i8042.c
@@ -189,7 +189,7 @@ static u32 kbd_read_data(void)
state.mcount--;
kvm__irq_line(state.kvm, AUX_IRQ, 0);
kbd_update_irq();
- } else if (state.kcount == 0) {
+ } else {
i = state.kread - 1;
if (i 0)
i = QUEUE_SIZE;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] kvm tools: close opened file
The file should be closed before return. Signed-off-by: Cong Ding ding...@gmail.com --- tools/kvm/builtin-setup.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/kvm/builtin-setup.c b/tools/kvm/builtin-setup.c index c5b0566..8b45c56 100644 --- a/tools/kvm/builtin-setup.c +++ b/tools/kvm/builtin-setup.c @@ -159,12 +159,12 @@ static int copy_passwd(const char *guestfs_name) return -1; ret = fprintf(file, root:x:0:0:root:/root:/bin/sh\n); - if (ret 0) - return ret; + if (ret 0) + ret = 0; fclose(file); - return 0; + return ret; } static int make_guestfs_symlink(const char *guestfs_name, const char *path) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sparc: kernel/sbus.c: fix memory leakage
On Wed, Jan 16, 2013 at 10:13:09PM +0100, Sam Ravnborg wrote: On Mon, Jan 14, 2013 at 10:36:08PM +0100, Cong Ding wrote: the variable iommu and strbuf are not freed if it goes to error. Signed-off-by: Cong Ding ding...@gmail.com --- arch/sparc/kernel/sbus.c |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c index 1271b3a..0b66e53 100644 --- a/arch/sparc/kernel/sbus.c +++ b/arch/sparc/kernel/sbus.c @@ -555,10 +555,10 @@ static void __init sbus_iommu_init(struct platform_device *op) iommu = kzalloc(sizeof(*iommu), GFP_ATOMIC); if (!iommu) - goto fatal_memory_error; + goto fatal_iommu_memory_error; strbuf = kzalloc(sizeof(*strbuf), GFP_ATOMIC); if (!strbuf) - goto fatal_memory_error; + goto fatal_strbuf_memory_error; op-dev.archdata.iommu = iommu; op-dev.archdata.stc = strbuf; @@ -656,6 +656,10 @@ static void __init sbus_iommu_init(struct platform_device *op) return; fatal_memory_error: + kfree(strbuf); +fatal_strbuf_memory_error: + kfree(iommu); +fatal_iommu_memory_error: prom_printf(sbus_iommu_init: Fatal memory allocation error.\n); } kfree is a noop if passed a null pointer. So you can just add the missing kfree's to fix this. Sam as far as I know, most codes in the kernel are in the same style as this patch, but if you really prefer to do in the way you described I can send a new version. Let me know. - cong -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] sparc: kernel/sbus.c: fix memory leakage
the variable iommu and strbuf are not freed if it goes to error. Signed-off-by: Cong Ding ding...@gmail.com --- arch/sparc/kernel/sbus.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c index 1271b3a..78aa26b 100644 --- a/arch/sparc/kernel/sbus.c +++ b/arch/sparc/kernel/sbus.c @@ -656,6 +656,8 @@ static void __init sbus_iommu_init(struct platform_device *op) return; fatal_memory_error: + kfree(strbuf); + kfree(iommu); prom_printf(sbus_iommu_init: Fatal memory allocation error.\n); } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: serial/vt8500_serial.c: fix bug caused by missing {}
It is obviously here should be braced by {} in the if branch (more than 1
line in the if branch), and by the
coding style document of the kernel I also add {} to the else branch.
Signed-off-by: Cong Ding ding...@gmail.com
---
drivers/tty/serial/vt8500_serial.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 8fd1814..ac46a6e 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -567,12 +567,13 @@ static int vt8500_serial_probe(struct platform_device
*pdev)
if (!mmres || !irqres)
return -ENODEV;
- if (np)
+ if (np) {
port = of_alias_get_id(np, serial);
if (port VT8500_MAX_PORTS)
port = -1;
- else
+ } else {
port = -1;
+ }
if (port 0) {
/* calculate the port id */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: serial/68328serial.c: remove unnecessary null pointer check
The pointer info is dereferened in line 1009, so it is not necessary to check null again in line 1012. Signed-off-by: Cong Ding ding...@gmail.com --- drivers/tty/serial/68328serial.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/68328serial.c b/drivers/tty/serial/68328serial.c index f99a845..4f7c0d2 100644 --- a/drivers/tty/serial/68328serial.c +++ b/drivers/tty/serial/68328serial.c @@ -1009,7 +1009,7 @@ static void rs_close(struct tty_struct *tty, struct file * filp) m68328_uart *uart = uart_addr[info-line]; unsigned long flags; - if (!info || serial_paranoia_check(info, tty-name, rs_close)) + if (serial_paranoia_check(info, tty-name, rs_close)) return; local_irq_save(flags); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kvm: remove redundant "if" condition
After we check (state.kcount != 0), state.kcount has to be 0 in all the "else"
branchs.
Signed-off-by: Cong Ding
---
tools/kvm/hw/i8042.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kvm/hw/i8042.c b/tools/kvm/hw/i8042.c
index 9f8be6a..9035732 100644
--- a/tools/kvm/hw/i8042.c
+++ b/tools/kvm/hw/i8042.c
@@ -189,7 +189,7 @@ static u32 kbd_read_data(void)
state.mcount--;
kvm__irq_line(state.kvm, AUX_IRQ, 0);
kbd_update_irq();
- } else if (state.kcount == 0) {
+ } else {
i = state.kread - 1;
if (i < 0)
i = QUEUE_SIZE;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kvm: close opened file
The file should be closed before return. Signed-off-by: Cong Ding --- tools/kvm/builtin-setup.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/kvm/builtin-setup.c b/tools/kvm/builtin-setup.c index c5b0566..8b45c56 100644 --- a/tools/kvm/builtin-setup.c +++ b/tools/kvm/builtin-setup.c @@ -159,12 +159,12 @@ static int copy_passwd(const char *guestfs_name) return -1; ret = fprintf(file, "root:x:0:0:root:/root:/bin/sh\n"); - if (ret < 0) - return ret; + if (ret > 0) + ret = 0; fclose(file); - return 0; + return ret; } static int make_guestfs_symlink(const char *guestfs_name, const char *path) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v] media: dvb-frontends: remove unnecessary null pointer check
The address of a variable is impossible to be null, so we remove the check.
Signed-off-by: Cong Ding
---
sorry for sending again. I didn't notice there are another 2 places with the
same issue.
- cong
drivers/media/dvb-frontends/stv0900_core.c | 14 --
drivers/media/dvb-frontends/stv0900_sw.c |7 ++-
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/media/dvb-frontends/stv0900_core.c
b/drivers/media/dvb-frontends/stv0900_core.c
index 0fb34e1..e5a87b5 100644
--- a/drivers/media/dvb-frontends/stv0900_core.c
+++ b/drivers/media/dvb-frontends/stv0900_core.c
@@ -524,11 +524,8 @@ void stv0900_set_tuner(struct dvb_frontend *fe, u32
frequency,
struct dvb_frontend_ops *frontend_ops = NULL;
struct dvb_tuner_ops *tuner_ops = NULL;
- if (>ops)
- frontend_ops = >ops;
-
- if (_ops->tuner_ops)
- tuner_ops = _ops->tuner_ops;
+ frontend_ops = >ops;
+ tuner_ops = _ops->tuner_ops;
if (tuner_ops->set_frequency) {
if ((tuner_ops->set_frequency(fe, frequency)) < 0)
@@ -552,11 +549,8 @@ void stv0900_set_bandwidth(struct dvb_frontend *fe, u32
bandwidth)
struct dvb_frontend_ops *frontend_ops = NULL;
struct dvb_tuner_ops *tuner_ops = NULL;
- if (>ops)
- frontend_ops = >ops;
-
- if (_ops->tuner_ops)
- tuner_ops = _ops->tuner_ops;
+ frontend_ops = >ops;
+ tuner_ops = _ops->tuner_ops;
if (tuner_ops->set_bandwidth) {
if ((tuner_ops->set_bandwidth(fe, bandwidth)) < 0)
diff --git a/drivers/media/dvb-frontends/stv0900_sw.c
b/drivers/media/dvb-frontends/stv0900_sw.c
index 4af2078..0a40edf 100644
--- a/drivers/media/dvb-frontends/stv0900_sw.c
+++ b/drivers/media/dvb-frontends/stv0900_sw.c
@@ -1167,11 +1167,8 @@ static u32 stv0900_get_tuner_freq(struct dvb_frontend
*fe)
struct dvb_tuner_ops *tuner_ops = NULL;
u32 freq = 0;
- if (>ops)
- frontend_ops = >ops;
-
- if (_ops->tuner_ops)
- tuner_ops = _ops->tuner_ops;
+ frontend_ops = >ops;
+ tuner_ops = _ops->tuner_ops;
if (tuner_ops->get_frequency) {
if ((tuner_ops->get_frequency(fe, )) < 0)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] media: dvb-frontends/stv0900_core.c: remove unnecessary null pointer check
The address of a variable is impossible to be null, so we remove the check.
Signed-off-by: Cong Ding
---
drivers/media/dvb-frontends/stv0900_core.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/stv0900_core.c
b/drivers/media/dvb-frontends/stv0900_core.c
index 0fb34e1..612b872 100644
--- a/drivers/media/dvb-frontends/stv0900_core.c
+++ b/drivers/media/dvb-frontends/stv0900_core.c
@@ -524,11 +524,8 @@ void stv0900_set_tuner(struct dvb_frontend *fe, u32
frequency,
struct dvb_frontend_ops *frontend_ops = NULL;
struct dvb_tuner_ops *tuner_ops = NULL;
- if (>ops)
- frontend_ops = >ops;
-
- if (_ops->tuner_ops)
- tuner_ops = _ops->tuner_ops;
+ frontend_ops = >ops;
+ tuner_ops = _ops->tuner_ops;
if (tuner_ops->set_frequency) {
if ((tuner_ops->set_frequency(fe, frequency)) < 0)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage
There is a memory leakage in variable sg if it goes to error. Signed-off-by: Cong Ding --- drivers/staging/omapdrm/omap_gem_dmabuf.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c b/drivers/staging/omapdrm/omap_gem_dmabuf.c index b6c5b5c..a3236ab 100644 --- a/drivers/staging/omapdrm/omap_gem_dmabuf.c +++ b/drivers/staging/omapdrm/omap_gem_dmabuf.c @@ -53,10 +53,10 @@ static struct sg_table *omap_gem_map_dma_buf( /* this should be after _get_paddr() to ensure we have pages attached */ omap_gem_dma_sync(obj, dir); -out: - if (ret) - return ERR_PTR(ret); return sg; +out: + kfree(sg); + return ERR_PTR(ret); } static void omap_gem_unmap_dma_buf(struct dma_buf_attachment *attachment, -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: netfilter/xt_CT.c: fix uninitialized variable
On Tue, Jan 15, 2013 at 07:06:51PM +, Waskiewicz Jr, Peter P wrote: > On Tue, 2013-01-15 at 19:58 +0100, Cong Ding wrote: > > If CONFIG_NF_CONNTRACK_ZONES is not defined, the variable ret might be > > uninitialized when it goes to err1 through line 125 and 263 respectively. > > So I change these goto err1 to return -EINVAL directly. > > > > Signed-off-by: Cong Ding > > --- > > net/netfilter/xt_CT.c |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c > > index 2a08430..941f600 100644 > > --- a/net/netfilter/xt_CT.c > > +++ b/net/netfilter/xt_CT.c > > @@ -122,7 +122,7 @@ static int xt_ct_tg_check_v0(const struct > > xt_tgchk_param *par) > > > > #ifndef CONFIG_NF_CONNTRACK_ZONES > > if (info->zone) > > - goto err1; > > + return -EINVAL; > > #endif > > > > ret = nf_ct_l3proto_try_module_get(par->family); > > @@ -260,7 +260,7 @@ static int xt_ct_tg_check_v1(const struct > > xt_tgchk_param *par) > > > > #ifndef CONFIG_NF_CONNTRACK_ZONES > > if (info->zone) > > - goto err1; > > + return -EINVAL; > > #endif > > In dropping both goto's, you left the err1 label unused. Wouldn't just > initializing ret to -EINVAL be easier and cleaner? Then you wouldn't be > messing with the flow of the function. The label err1 are also used in line 130 and 298. I change it to "return -EINVAL" rather than initialize ret to -EINVAL is to keep it the same as line 115 and 253. Otherwise, we should change line 115 and 253 to be goto err1, too? - cong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
