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.
next prev parent 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