All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Julia Lawall <julia@diku.dk>
Cc: srostedt@redhat.com, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 1/3] kernel/trace/trace.c: introduce missing kfree
Date: Tue, 18 Nov 2008 22:42:17 +0000	[thread overview]
Message-ID: <20081118144217.34ffa4e1.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0811141904580.10023@pc-004.diku.dk>

On Fri, 14 Nov 2008 19:05:31 +0100 (CET)
Julia Lawall <julia@diku.dk> wrote:

> From: Julia Lawall <julia@diku.dk>
> 
> Error handling code following a kzalloc should free the allocated data.
> 
> The semantic match that finds the problem is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
> 
> // <smpl>
> @r exists@
> local idexpression x;
> statement S;
> expression E;
> identifier f,l;
> position p1,p2;
> expression *ptr != NULL;
> @@
> 
> (
> if ((x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...)) = NULL) S
> |
> x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
> ...
> if (x = NULL) S
> )
> <... when != x
>      when != if (...) { <+...x...+> }
> x->f = E
> ...>
> (
>  return \(0\|<+...x...+>\|ptr\);
> |
>  return@p2 ...;
> )
> 
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
> 
> print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
> // </smpl>
> 
> Signed-off-by: Julia Lawall <julia@diku.dk>
> ---
>  kernel/trace/trace.c          |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 697eda3..d86e325 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1936,6 +1936,7 @@ __tracing_open(struct inode *inode, struct file *file, int *ret)
>  			ring_buffer_read_finish(iter->buffer_iter[cpu]);
>  	}
>  	mutex_unlock(&trace_types_lock);
> +	kfree(iter);
>  
>  	return ERR_PTR(-ENOMEM);
>  }

Nobody seems to have applied this to anything yet?

That function really needs help.  Sometimes it will return NULL and
will set *ret.  Other times it will return ERR_PTR(-ENOMEM) and will
fail to write anything to *ret.  One caller (tracing_open) ignores the
return value.  Another caller (tracing_lt_open) tests the
possibly-uninitialised `ret' and then blindly dereferences the
possibly-IS_ERR return value.

Or something like that.  I looked at it long enough to convince myself
that it needs fixing ;)



WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Julia Lawall <julia@diku.dk>
Cc: srostedt@redhat.com, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 1/3] kernel/trace/trace.c: introduce missing kfree
Date: Tue, 18 Nov 2008 14:42:17 -0800	[thread overview]
Message-ID: <20081118144217.34ffa4e1.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0811141904580.10023@pc-004.diku.dk>

On Fri, 14 Nov 2008 19:05:31 +0100 (CET)
Julia Lawall <julia@diku.dk> wrote:

> From: Julia Lawall <julia@diku.dk>
> 
> Error handling code following a kzalloc should free the allocated data.
> 
> The semantic match that finds the problem is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
> 
> // <smpl>
> @r exists@
> local idexpression x;
> statement S;
> expression E;
> identifier f,l;
> position p1,p2;
> expression *ptr != NULL;
> @@
> 
> (
> if ((x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...)) == NULL) S
> |
> x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
> ...
> if (x == NULL) S
> )
> <... when != x
>      when != if (...) { <+...x...+> }
> x->f = E
> ...>
> (
>  return \(0\|<+...x...+>\|ptr\);
> |
>  return@p2 ...;
> )
> 
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
> 
> print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
> // </smpl>
> 
> Signed-off-by: Julia Lawall <julia@diku.dk>
> ---
>  kernel/trace/trace.c          |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 697eda3..d86e325 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1936,6 +1936,7 @@ __tracing_open(struct inode *inode, struct file *file, int *ret)
>  			ring_buffer_read_finish(iter->buffer_iter[cpu]);
>  	}
>  	mutex_unlock(&trace_types_lock);
> +	kfree(iter);
>  
>  	return ERR_PTR(-ENOMEM);
>  }

Nobody seems to have applied this to anything yet?

That function really needs help.  Sometimes it will return NULL and
will set *ret.  Other times it will return ERR_PTR(-ENOMEM) and will
fail to write anything to *ret.  One caller (tracing_open) ignores the
return value.  Another caller (tracing_lt_open) tests the
possibly-uninitialised `ret' and then blindly dereferences the
possibly-IS_ERR return value.

Or something like that.  I looked at it long enough to convince myself
that it needs fixing ;)



  reply	other threads:[~2008-11-18 22:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-14 18:05 [PATCH 1/3] kernel/trace/trace.c: introduce missing kfree Julia Lawall
2008-11-14 18:05 ` Julia Lawall
2008-11-18 22:42 ` Andrew Morton [this message]
2008-11-18 22:42   ` Andrew Morton
2008-11-19  8:52   ` Ingo Molnar
2008-11-19  8:52     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081118144217.34ffa4e1.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=julia@diku.dk \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=srostedt@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.