From: Douglas Gilbert <dgilbert@interlog.com>
To: SCSI development list <linux-scsi@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Cc: Bart Van Assche <bvanassche@acm.org>,
"Martin K. Petersen" <martin.petersen@ORACLE.COM>,
USB list <linux-usb@vger.kernel.org>
Subject: lib/scatterlist.c : sgl_alloc_order promises more than it delivers
Date: Thu, 24 Sep 2020 21:46:05 -0400 [thread overview]
Message-ID: <b9f5c065-7662-30e0-8cbd-27a77d28611e@interlog.com> (raw)
The signature of this exported function is:
struct scatterlist *sgl_alloc_order(unsigned long long length,
unsigned int order, bool chainable,
gfp_t gfp, unsigned int *nent_p)
That first argument would be better named num_bytes (rather than length).
Its type (unsigned long long) seems to promise large allocations (is that
64 or 128 bits?). Due to the implementation it doesn't matter due to this
check in that function's definition:
/* Check for integer overflow */
if (length > (nent << (PAGE_SHIFT + order)))
return NULL;
Well _integers_ don't wrap, but that pedantic point aside, 'nent' is an
unsigned int which means the rhs expression cannot represent 2^32 or
higher. So if length >= 2^32 the function fails (i.e. returns NULL).
On 8 GiB and 16 GiB machines I can easily build 6 or 12 GiB sgl_s (with
scsi_debug) but only if no single allocation is >= 4 GiB due to the
above check.
So is the above check intended to do that or is it a bug?
Any progress with the "[PATCH] sgl_alloc_order: memory leak" bug fix
posted on 20200920 ?
sgl_free() is badly named as it leaks for order > 0 .
Doug Gilbert
PS1 vmalloc() which I would like to replace with sgl_alloc_order() in the
scsi_debug driver, does not have a 4 GB limit.
PS2 Here are the users of sgl_free() under the drivers directory:
find . -name '*.c' -exec grep "sgl_free(" {} \; -print
sgl_free(cmd->req.sg);
sgl_free(cmd->req.sg);
sgl_free(cmd->req.sg);
sgl_free(cmd->req.sg);
./nvme/target/tcp.c
sgl_free(req->sg);
sgl_free(req->sg);
sgl_free(req->metadata_sg);
./nvme/target/core.c
sgl_free(fod->data_sg);
./nvme/target/fc.c
sgl_free(sgl);
./usb/usbip/stub_rx.c
sgl_free(urb->sg);
sgl_free(priv->sgl);
./usb/usbip/stub_main.c
next reply other threads:[~2020-09-25 1:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 1:46 Douglas Gilbert [this message]
2020-09-25 2:34 ` lib/scatterlist.c : sgl_alloc_order promises more than it delivers Bart Van Assche
2020-09-25 4:55 ` Douglas Gilbert
2020-09-26 4:32 ` Bart Van Assche
2020-10-11 21:21 ` Douglas Gilbert
2020-10-11 22:24 ` 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=b9f5c065-7662-30e0-8cbd-27a77d28611e@interlog.com \
--to=dgilbert@interlog.com \
--cc=bvanassche@acm.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=martin.petersen@ORACLE.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;
as well as URLs for NNTP newsgroup(s).