All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Sasha Levin <sasha.levin@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kexec: fix memory leak in function kimage_normal_alloc
Date: Fri, 22 Feb 2013 13:59:38 -0800	[thread overview]
Message-ID: <20130222135938.c6f28ff5.akpm@linux-foundation.org> (raw)
In-Reply-To: <5126F5BD.1030602@cn.fujitsu.com>

On Fri, 22 Feb 2013 12:36:13 +0800
Zhang Yanfei <zhangyanfei@cn.fujitsu.com> wrote:

> If kimage_normal_alloc() fails to alloc pages for image->swap_page, it
> should call kimage_free_page_list() to free allocated pages in
> image->control_pages list before it frees image.
>
> ...
>
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -223,6 +223,8 @@ out:
>  
>  }
>  
> +static void kimage_free_page_list(struct list_head *list);
> +
>  static int kimage_normal_alloc(struct kimage **rimage, unsigned long entry,
>  				unsigned long nr_segments,
>  				struct kexec_segment __user *segments)
> @@ -248,22 +250,22 @@ static int kimage_normal_alloc(struct kimage **rimage, unsigned long entry,
>  					   get_order(KEXEC_CONTROL_PAGE_SIZE));
>  	if (!image->control_code_page) {
>  		printk(KERN_ERR "Could not allocate control_code_buffer\n");
> -		goto out;
> +		goto out_free;
>  	}
>  
>  	image->swap_page = kimage_alloc_control_pages(image, 0);
>  	if (!image->swap_page) {
>  		printk(KERN_ERR "Could not allocate swap buffer\n");
> -		goto out;
> +		goto out_free;
>  	}
>  
> -	result = 0;
> - out:
> -	if (result == 0)
> -		*rimage = image;
> -	else
> -		kfree(image);
> +	*rimage = image;
> +	return 0;
>  
> +out_free:
> +	kimage_free_page_list(&image->control_pages);
> +	kfree(image);
> +out:
>  	return result;
>  }

kimage_alloc_normal_control_pages() won't add any pages to the image if
one of its allocation attemtps failed.  So afaict the first `goto
out_free' could be just `goto out'.

The second `goto out_free' does appear to be needed: it frees the pages
allocated by the first call to kimage_alloc_control_pages().  I think. 
The kimage_alloc_control_pages() handling of image->type is a bit
twisty.

Please double-check the logic?

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Sasha Levin <sasha.levin@oracle.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kexec: fix memory leak in function kimage_normal_alloc
Date: Fri, 22 Feb 2013 13:59:38 -0800	[thread overview]
Message-ID: <20130222135938.c6f28ff5.akpm@linux-foundation.org> (raw)
In-Reply-To: <5126F5BD.1030602@cn.fujitsu.com>

On Fri, 22 Feb 2013 12:36:13 +0800
Zhang Yanfei <zhangyanfei@cn.fujitsu.com> wrote:

> If kimage_normal_alloc() fails to alloc pages for image->swap_page, it
> should call kimage_free_page_list() to free allocated pages in
> image->control_pages list before it frees image.
>
> ...
>
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -223,6 +223,8 @@ out:
>  
>  }
>  
> +static void kimage_free_page_list(struct list_head *list);
> +
>  static int kimage_normal_alloc(struct kimage **rimage, unsigned long entry,
>  				unsigned long nr_segments,
>  				struct kexec_segment __user *segments)
> @@ -248,22 +250,22 @@ static int kimage_normal_alloc(struct kimage **rimage, unsigned long entry,
>  					   get_order(KEXEC_CONTROL_PAGE_SIZE));
>  	if (!image->control_code_page) {
>  		printk(KERN_ERR "Could not allocate control_code_buffer\n");
> -		goto out;
> +		goto out_free;
>  	}
>  
>  	image->swap_page = kimage_alloc_control_pages(image, 0);
>  	if (!image->swap_page) {
>  		printk(KERN_ERR "Could not allocate swap buffer\n");
> -		goto out;
> +		goto out_free;
>  	}
>  
> -	result = 0;
> - out:
> -	if (result == 0)
> -		*rimage = image;
> -	else
> -		kfree(image);
> +	*rimage = image;
> +	return 0;
>  
> +out_free:
> +	kimage_free_page_list(&image->control_pages);
> +	kfree(image);
> +out:
>  	return result;
>  }

kimage_alloc_normal_control_pages() won't add any pages to the image if
one of its allocation attemtps failed.  So afaict the first `goto
out_free' could be just `goto out'.

The second `goto out_free' does appear to be needed: it frees the pages
allocated by the first call to kimage_alloc_control_pages().  I think. 
The kimage_alloc_control_pages() handling of image->type is a bit
twisty.

Please double-check the logic?

  reply	other threads:[~2013-02-22 21:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-22  4:36 [PATCH] kexec: fix memory leak in function kimage_normal_alloc Zhang Yanfei
2013-02-22  4:36 ` Zhang Yanfei
2013-02-22 21:59 ` Andrew Morton [this message]
2013-02-22 21:59   ` Andrew Morton
2013-02-23 13:48   ` Yanfei Zhang
2013-02-23 13:48     ` Yanfei Zhang
2013-02-22 22:54 ` Simon Horman
2013-02-22 22:54   ` Simon Horman

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=20130222135938.c6f28ff5.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sasha.levin@oracle.com \
    --cc=zhangyanfei@cn.fujitsu.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.