public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tursulin@ursulin.net" <tursulin@ursulin.net>
Cc: "tvrtko.ursulin@intel.com" <tvrtko.ursulin@intel.com>,
	"hare@suse.com" <hare@suse.com>,
	"jthumshirn@suse.de" <jthumshirn@suse.de>,
	"axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH 1/6] lib/scatterlist: Tidy types and fix overflow checking in sgl_alloc_order
Date: Wed, 7 Mar 2018 16:10:37 +0000	[thread overview]
Message-ID: <1520439036.2890.13.camel@wdc.com> (raw)
In-Reply-To: <20180307124712.14963-2-tvrtko.ursulin@linux.intel.com>

On Wed, 2018-03-07 at 12:47 +0000, Tvrtko Ursulin wrote:
> sgl_alloc_order explicitly takes a 64-bit length (unsigned long long) but
> then rejects it in overflow checking if greater than 4GiB allocation was
> requested. This is a consequence of using unsigned int for the right hand
> side condition which then natuarally overflows when shifted left, earlier
> than nent otherwise would.
> 
> Fix is to promote the right hand side of the conditional to unsigned long.

Agreed.

> It is also not useful to allow for 64-bit lenght on 32-bit platforms so
> I have changed this type to a natural unsigned long. Like this it changes
> size naturally depending on the architecture.

I do not agree. Although uncommon, it is possible that e.g. a SCSI initiator
sends a transfer of more than 4 GB to a target system and that that transfer
must not be split. Since this code is used by the SCSI target, I think that's
an example of an application where it is useful to allow allocations of more
than 4 GB at once on a 32-bit system.

> 2.
> 
> elem_len should not be explicitly sized u32 but unsigned int, to match
> the underlying struct scatterlist nents type. Same for the nent_p output
> parameter type.

Are you sure it is useful to support allocations with an order that exceeds
(31 - PAGE_SHIFT)? Since memory gets fragmented easily in the Linux kernel I
think that it's unlikely that such allocations will succeed.

> I renamed this to chunk_len and consolidated its use throughout the
> function.

Please undo this change such that the diff remains as short as possible.

> -void sgl_free_n_order(struct scatterlist *sgl, int nents, int order)
> +void sgl_free_n_order(struct scatterlist *sgl, unsigned int nents,
> +		      unsigned int order)
>  {
>  	struct scatterlist *sg;
>  	struct page *page;
> -	int i;
> +	unsigned int i;
>  
>  	for_each_sg(sgl, sg, nents, i) {
>  		if (!sg)
> @@ -583,9 +587,9 @@ EXPORT_SYMBOL(sgl_free_n_order);
>   * @sgl: Scatterlist with one or more elements
>   * @order: Second argument for __free_pages()
>   */
> -void sgl_free_order(struct scatterlist *sgl, int order)
> +void sgl_free_order(struct scatterlist *sgl, unsigned int order)
>  {
> -	sgl_free_n_order(sgl, INT_MAX, order);
> +	sgl_free_n_order(sgl, UINT_MAX, order);
>  }
>  EXPORT_SYMBOL(sgl_free_order);

Do you have an application that calls these functions to allocate more than
INT_MAX * PAGE_SIZE bytes at once? If not, please leave these changes out.

Thanks,

Bart.

  reply	other threads:[~2018-03-07 16:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 12:47 [PATCH 0/6] lib/scatterlist: Small SGL tidy Tvrtko Ursulin
2018-03-07 12:47 ` [PATCH 1/6] lib/scatterlist: Tidy types and fix overflow checking in sgl_alloc_order Tvrtko Ursulin
2018-03-07 16:10   ` Bart Van Assche [this message]
2018-03-07 17:06     ` Tvrtko Ursulin
2018-03-09 14:04       ` Tvrtko Ursulin
2018-03-07 12:47 ` [PATCH 2/6] lib/scatterlist: Skip requesting zeroed allocations " Tvrtko Ursulin
2018-03-07 15:35   ` Andy Shevchenko
2018-03-07 17:31     ` Tvrtko Ursulin
2018-03-07 12:47 ` [PATCH 3/6] lib/scatterlist: Do not leak pages when high-order allocation fails Tvrtko Ursulin
2018-03-07 16:16   ` Bart Van Assche
2018-03-07 17:06     ` Tvrtko Ursulin
2018-03-07 12:47 ` [PATCH 4/6] lib/scatterlist: Unexport some trivial wrappers Tvrtko Ursulin
2018-03-07 16:19   ` Bart Van Assche
2018-03-07 17:10     ` Tvrtko Ursulin
2018-03-07 12:47 ` [PATCH 5/6] lib/scatterlist: Drop unused sgl_free_order Tvrtko Ursulin
2018-03-07 12:47 ` [PATCH 6/6] lib/scatterlist: Drop order argument from sgl_free_n_order Tvrtko Ursulin
2018-03-07 16:23   ` Bart Van Assche
2018-03-07 17:23     ` Tvrtko Ursulin
2018-03-07 17:33       ` Bart Van Assche
2018-03-07 18:30   ` James Bottomley
2018-03-08  7:59     ` Tvrtko Ursulin
2018-03-08 15:56       ` Bart Van Assche
2018-03-08 17:06         ` Tvrtko Ursulin
2018-03-07 18:38 ` [PATCH 0/6] lib/scatterlist: Small SGL tidy Bart Van Assche
2018-03-08  8:04   ` Tvrtko Ursulin

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=1520439036.2890.13.camel@wdc.com \
    --to=bart.vanassche@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hare@suse.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tursulin@ursulin.net \
    --cc=tvrtko.ursulin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox