From: Bodo Stroesser <bostroesser@gmail.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Douglas Gilbert <dgilbert@interlog.com>,
linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
target-devel@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, martin.petersen@oracle.com,
jejb@linux.vnet.ibm.com, ddiss@suse.de, bvanassche@acm.org
Subject: Re: [PATCH v6 1/4] sgl_alloc_order: remove 4 GiB limit, sgl_free() warning
Date: Tue, 19 Jan 2021 19:39:23 +0100 [thread overview]
Message-ID: <05a7b524-aee2-fd1d-e342-b85f355adb82@gmail.com> (raw)
In-Reply-To: <20210119181714.GA909645@ziepe.ca>
On 19.01.21 19:17, Jason Gunthorpe wrote:
> On Tue, Jan 19, 2021 at 07:08:32PM +0100, Bodo Stroesser wrote:
>> On 19.01.21 19:03, Jason Gunthorpe wrote:
>>> On Tue, Jan 19, 2021 at 06:24:49PM +0100, Bodo Stroesser wrote:
>>>>
>>>> I had a second look into math.h, but I don't find any reason why round_up
>>>> could overflow. Can you give a hint please?
>>>
>>> #define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)
>>> ^^^^^
>>>
>>> That +1 can overflow
>>
>> But that would be a unsigned long long overflow. I considered this to
>> not be relevant.
>
> Why not? It still makes nents 0 and still causes a bad bug
>
Generally spoken, you of course are right.
OTOH, if someone tries to allocate such big sgls, then we will run into
trouble during memory allocation even without overrun.
Anyway, if we first calculate nent and nalloc and then check with
if ((unsigned long long)nalloc << (PAGE_SHIFT + order) < length)
return NULL;
I think we would have checked against all kind of overrun in a single
step. Or am I missing something?
Bodo
next prev parent reply other threads:[~2021-01-19 18:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-18 16:30 [PATCH v6 0/4] scatterlist: add new capabilities Douglas Gilbert
2021-01-18 16:30 ` [PATCH v6 1/4] sgl_alloc_order: remove 4 GiB limit, sgl_free() warning Douglas Gilbert
2021-01-18 18:28 ` Jason Gunthorpe
2021-01-18 20:08 ` Douglas Gilbert
2021-01-18 20:24 ` Jason Gunthorpe
2021-01-18 21:22 ` Bodo Stroesser
2021-01-18 23:48 ` Jason Gunthorpe
2021-01-19 1:27 ` Douglas Gilbert
2021-01-19 12:59 ` Jason Gunthorpe
2021-01-19 17:24 ` Bodo Stroesser
2021-01-19 18:03 ` Jason Gunthorpe
2021-01-19 18:08 ` Bodo Stroesser
2021-01-19 18:17 ` Jason Gunthorpe
2021-01-19 18:39 ` Bodo Stroesser [this message]
2021-01-18 20:46 ` Bodo Stroesser
2021-01-18 16:30 ` [PATCH v6 2/4] scatterlist: add sgl_copy_sgl() function Douglas Gilbert
2021-01-18 16:30 ` [PATCH v6 3/4] scatterlist: add sgl_compare_sgl() function Douglas Gilbert
2021-01-18 23:27 ` David Disseldorp
2021-01-19 1:04 ` Douglas Gilbert
2021-01-19 11:50 ` David Disseldorp
2021-01-18 16:30 ` [PATCH v6 4/4] scatterlist: add sgl_memset() Douglas Gilbert
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=05a7b524-aee2-fd1d-e342-b85f355adb82@gmail.com \
--to=bostroesser@gmail.com \
--cc=bvanassche@acm.org \
--cc=ddiss@suse.de \
--cc=dgilbert@interlog.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=jgg@ziepe.ca \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=target-devel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).