2008-03-02 23:15:24

by Jesper Juhl

Subject: [PATCH] leak less memory in failure paths of alloc_rt_sched_group()

In kernel/sched.c b/kernel/sched.c::alloc_rt_sched_group() we currently do
some paired memory allocations, and if one fails we bail out without
freeing the previous one.

If we fail inside the loop we should proably roll the whole thing back.
This patch does not do that, it simply frees the first member of the
paired alloc if the second fails. This is not perfect, but it's a simple
change that will, at least, result in us leaking a little less than we
currently do when an allocation fails.

So, not perfect, but better than what we currently have.
Please consider applying.


Signed-off-by: Jesper Juhl <[email protected]>
---

sched.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index f06950c..360857f 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -7685,8 +7685,10 @@ static int alloc_rt_sched_group(struct task_group *tg)
if (!tg->rt_rq)
goto err;
tg->rt_se = kzalloc(sizeof(rt_se) * NR_CPUS, GFP_KERNEL);
- if (!tg->rt_se)
+ if (!tg->rt_se) {
+ kfree(tg->rt_rq);
goto err;
+ }

tg->rt_runtime = 0;

@@ -7700,8 +7702,10 @@ static int alloc_rt_sched_group(struct task_group *tg)

rt_se = kmalloc_node(sizeof(struct sched_rt_entity),
GFP_KERNEL|__GFP_ZERO, cpu_to_node(i));
- if (!rt_se)
+ if (!rt_se) {
+ kfree(rt_rq);
goto err;
+ }

init_tg_rt_entry(rq, tg, rt_rq, rt_se, i, 0);
}

2008-03-02 23:20:27

by Peter Zijlstra

Subject: Re: [PATCH] leak less memory in failure paths of alloc_rt_sched_group()

On Mon, 2008-03-03 at 00:09 +0100, Jesper Juhl wrote:
> In kernel/sched.c b/kernel/sched.c::alloc_rt_sched_group() we currently do
> some paired memory allocations, and if one fails we bail out without
> freeing the previous one.
>
> If we fail inside the loop we should proably roll the whole thing back.
> This patch does not do that, it simply frees the first member of the
> paired alloc if the second fails. This is not perfect, but it's a simple
> change that will, at least, result in us leaking a little less than we
> currently do when an allocation fails.
>
> So, not perfect, but better than what we currently have.
> Please consider applying.

Doesn't the following handle that:

sched_create_group()
{
...
if (!alloc_rt_sched_group())
goto err;
...

err:
free_sched_group();
}


free_sched_group()
{
...
free_rt_sched_group();
...
}

free_rt_sched_group()
{
free all relevant stuff
}

2008-03-02 23:29:36

by Jesper Juhl

Subject: Re: [PATCH] leak less memory in failure paths of alloc_rt_sched_group()

On 03/03/2008, Peter Zijlstra <[email protected]> wrote:
>
> On Mon, 2008-03-03 at 00:09 +0100, Jesper Juhl wrote:
> > In kernel/sched.c b/kernel/sched.c::alloc_rt_sched_group() we currently do
> > some paired memory allocations, and if one fails we bail out without
> > freeing the previous one.
> >
> > If we fail inside the loop we should proably roll the whole thing back.
> > This patch does not do that, it simply frees the first member of the
> > paired alloc if the second fails. This is not perfect, but it's a simple
> > change that will, at least, result in us leaking a little less than we
> > currently do when an allocation fails.
> >
> > So, not perfect, but better than what we currently have.
> > Please consider applying.
>
>
> Doesn't the following handle that:
>
> sched_create_group()
> {
> ...
> if (!alloc_rt_sched_group())
> goto err;
> ...
>
> err:
> free_sched_group();
> }
>
>
> free_sched_group()
> {
> ...
> free_rt_sched_group();
> ...
> }
>
> free_rt_sched_group()
> {
> free all relevant stuff
> }
>

Hmmm, it might. I must admit I only looked at alloc_rt_sched_group()
isolated, and what I saw looked like leaks. It seems I need to do a
more thorough reading of the code to be dead sure.

--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html