All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Tvrtko Ursulin <tursulin@ursulin.net>, linux-kernel@vger.kernel.org
Cc: tvrtko.ursulin@linux.intel.com,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	Bart Van Assche <bart.vanassche@wdc.com>,
	Hannes Reinecke <hare@suse.com>,
	Johannes Thumshirn <jthumshirn@suse.de>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 4/6] lib/scatterlist: Do not leak pages when high-order allocation fails
Date: Wed, 03 Oct 2018 08:31:40 -0700	[thread overview]
Message-ID: <1538580700.205649.10.camel@acm.org> (raw)
In-Reply-To: <20180926141625.17727-5-tvrtko.ursulin@linux.intel.com>

On Wed, 2018-09-26 at 15:16 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> If a higher-order allocation fails, the existing abort and cleanup path
> would consider all segments allocated so far as 0-order page allocations
> and would therefore leak memory.
> 
> Fix this by cleaning up using sgl_free_n_order which allows the correct
> page order to be passed in.
> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Bart Van Assche <bart.vanassche@wdc.com>
> Cc: Hannes Reinecke <hare@suse.com>
> Cc: Johannes Thumshirn <jthumshirn@suse.de>
> Cc: Jens Axboe <axboe@kernel.dk>
> ---
>  lib/scatterlist.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> index 3cc01cd82242..0caed79d7291 100644
> --- a/lib/scatterlist.c
> +++ b/lib/scatterlist.c
> @@ -481,7 +481,7 @@ struct scatterlist *sgl_alloc_order(unsigned long length, unsigned int order,
>  {
>  	struct scatterlist *sgl, *sg;
>  	struct page *page;
> -	unsigned int nent, nalloc;
> +	unsigned int nent, nalloc, i;
>  	u32 elem_len;
>  
>  	nent = round_up(length, PAGE_SIZE << order) >> (PAGE_SHIFT + order);
> @@ -501,17 +501,19 @@ struct scatterlist *sgl_alloc_order(unsigned long length, unsigned int order,
>  
>  	sg_init_table(sgl, nalloc);
>  	sg = sgl;
> +	i = 0;
>  	while (length) {
>  		elem_len = min_t(u64, length, PAGE_SIZE << order);
>  		page = alloc_pages(gfp, order);
>  		if (!page) {
> -			sgl_free(sgl);
> +			sgl_free_n_order(sgl, i, order);
>  			return NULL;
>  		}
>  
>  		sg_set_page(sg, page, elem_len, 0);
>  		length -= elem_len;
>  		sg = sg_next(sg);
> +		i++;
>  	}
>  	WARN_ONCE(length, "length = %ld\n", length);
>  	if (nent_p)

sg_init_table() clears all page pointers and sgl_free_n_order() can handle
elements of which the page pointer is zero. So I think if
sgl_free_n_order(sgl, i, order) would be changed into sgl_free_n_order(sgl,
UINT_MAX, order) that the variable 'i' can be left out.

Bart.


  reply	other threads:[~2018-10-03 15:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-26 14:16 [PATCH 0/6] lib/scatterlist: sgl API fixes and cleanups Tvrtko Ursulin
2018-09-26 14:16 ` [PATCH 1/6] lib/scatterlist: Use natural long for sgl_alloc(_order) length parameter Tvrtko Ursulin
2018-10-03 15:26   ` Bart Van Assche
2018-09-26 14:16 ` [PATCH 2/6] lib/scatterlist: Use consistent types in sgl API Tvrtko Ursulin
2018-10-03 15:28   ` Bart Van Assche
2018-09-26 14:16 ` [PATCH 3/6] lib/scatterlist: Skip requesting zeroed allocations in sgl_alloc_order Tvrtko Ursulin
2018-10-03 15:28   ` Bart Van Assche
2018-09-26 14:16 ` [PATCH 4/6] lib/scatterlist: Do not leak pages when high-order allocation fails Tvrtko Ursulin
2018-10-03 15:31   ` Bart Van Assche [this message]
2018-09-26 14:16 ` [PATCH 5/6] lib/scatterlist: Use appropriate type for elem_len in sgl_alloc_order Tvrtko Ursulin
2018-10-03 15:32   ` Bart Van Assche
2018-09-26 14:16 ` [PATCH 6/6] lib/scatterlist: Fix overflow check " Tvrtko Ursulin
2018-10-03 15:34   ` Bart Van Assche
2018-10-03 15:56 ` [PATCH 0/6] lib/scatterlist: sgl API fixes and cleanups Bart Van Assche

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=1538580700.205649.10.camel@acm.org \
    --to=bvanassche@acm.org \
    --cc=axboe@kernel.dk \
    --cc=bart.vanassche@wdc.com \
    --cc=hare@suse.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tursulin@ursulin.net \
    --cc=tvrtko.ursulin@intel.com \
    --cc=tvrtko.ursulin@linux.intel.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.