In fs/dlm/lock.c in the dlm_scan_waiters() function there are 3 small
issues:
1) first time through the loop we allocate memory for 'warned', if we
then (in the loop) don't take the "if (!warned)" path and loop again,
the second time through the loop we'll allocate memory again and store
it to 'warned' without freeing the previous allocation - this leaks
memory.
Fix this by kfree'ing 'warned' just before the in-loop allocation. The
first time through the loop this will result in a pointless
kfree(NULL), but that's a small price to pay for avoiding a mem leak
IMHO.
2) There's no need to test the return value of the allocation and do a
memset if is succeedes. Just use kzalloc() to obtain zeroed memory.
3) Since kfree() handles NULL pointers gracefully, the test of
'warned' against NULL before the kfree() after the loop is completely
pointless. Remove it.
Signed-off-by: Jesper Juhl <[email protected]>
---
fs/dlm/lock.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
compile tested only.
diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
index f71d0b5..a18ecff 100644
--- a/fs/dlm/lock.c
+++ b/fs/dlm/lock.c
@@ -849,9 +849,8 @@ void dlm_scan_waiters(struct dlm_ls *ls)
if (!num_nodes) {
num_nodes = ls->ls_num_nodes;
- warned = kmalloc(GFP_KERNEL, num_nodes * sizeof(int));
- if (warned)
- memset(warned, 0, num_nodes * sizeof(int));
+ kfree(warned);
+ warned = kzalloc(GFP_KERNEL, num_nodes * sizeof(int));
}
if (!warned)
continue;
@@ -863,9 +862,7 @@ void dlm_scan_waiters(struct dlm_ls *ls)
dlm_config.ci_waitwarn_us, lkb->lkb_wait_nodeid);
}
mutex_unlock(&ls->ls_waiters_mutex);
-
- if (warned)
- kfree(warned);
+ kfree(warned);
if (debug_expired)
log_debug(ls, "scan_waiters %u warn %u over %d us max %lld us",
--
1.7.6
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
On Wed, Jun 29, 2011 at 11:09:27PM +0200, Jesper Juhl wrote:
> In fs/dlm/lock.c in the dlm_scan_waiters() function there are 3 small
> issues:
>
> 1) first time through the loop we allocate memory for 'warned', if we
> then (in the loop) don't take the "if (!warned)" path and loop again,
> the second time through the loop we'll allocate memory again and store
> it to 'warned' without freeing the previous allocation - this leaks
> memory.
I don't think so; num_nodes won't be set to zero.
> 2) There's no need to test the return value of the allocation and do a
> memset if is succeedes. Just use kzalloc() to obtain zeroed memory.
fine
> 3) Since kfree() handles NULL pointers gracefully, the test of
> 'warned' against NULL before the kfree() after the loop is completely
> pointless. Remove it.
fine
ack if you want to push those two out yourself.
Dave
On Wed, 29 Jun 2011, David Teigland wrote:
> On Wed, Jun 29, 2011 at 11:09:27PM +0200, Jesper Juhl wrote:
> > In fs/dlm/lock.c in the dlm_scan_waiters() function there are 3 small
> > issues:
> >
> > 1) first time through the loop we allocate memory for 'warned', if we
> > then (in the loop) don't take the "if (!warned)" path and loop again,
> > the second time through the loop we'll allocate memory again and store
> > it to 'warned' without freeing the previous allocation - this leaks
> > memory.
>
> I don't think so; num_nodes won't be set to zero.
>
Hmm. How so? Maybe I'm missing something obvious, but;
num_nodes is initialized to zero at the beginning of the function, which
means that we'll definately do the first allocation in the loop.
We then set num_nodes equal to ls->ls_num_nodes - what guarantees that
this will not be zero so we won't do a second allocation (and leak) the
second time through the loop?
> > 2) There's no need to test the return value of the allocation and do a
> > memset if is succeedes. Just use kzalloc() to obtain zeroed memory.
>
> fine
>
> > 3) Since kfree() handles NULL pointers gracefully, the test of
> > 'warned' against NULL before the kfree() after the loop is completely
> > pointless. Remove it.
>
> fine
>
> ack if you want to push those two out yourself.
> Dave
Ok. I can resend a patch (tomorrow) with just those two changes and will
add your Acked-by:
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
On Wed, Jun 29, 2011 at 11:51:00PM +0200, Jesper Juhl wrote:
> > I don't think so; num_nodes won't be set to zero.
>
> Hmm. How so? Maybe I'm missing something obvious, but;
> num_nodes is initialized to zero at the beginning of the function, which
> means that we'll definately do the first allocation in the loop.
Zero is meant to mean "first time through the loop".
> We then set num_nodes equal to ls->ls_num_nodes - what guarantees that
> this will not be zero so we won't do a second allocation (and leak) the
> second time through the loop?
That's just the nature of a lockspace, I guess -- it doesn't make sense or
exist without nodes in it. I doubt any of the dlm code would work if that
weren't true.
Dave