From: John Hubbard <jhubbard@nvidia.com>
To: Souptick Joarder <jrdr.linux@gmail.com>, <akpm@linux-foundation.org>
Cc: <jgg@ziepe.ca>, <dan.j.williams@intel.com>,
<gregkh@linuxfoundation.org>, <arnd@arndb.de>,
<timur@freescale.com>, <galak@kernel.crashing.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [linux-next PATCH v3] drivers/virt/fsl_hypervisor: Fix error handling path
Date: Mon, 31 Aug 2020 15:58:19 -0700 [thread overview]
Message-ID: <82329783-739b-a315-8957-2c49a3ab1350@nvidia.com> (raw)
In-Reply-To: <1598911668-6178-1-git-send-email-jrdr.linux@gmail.com>
On 8/31/20 3:07 PM, Souptick Joarder wrote:
> First, when memory allocation for sg_list_unaligned failed, there
> is a bug of calling put_pages() as we haven't pinned any pages.
"we should unpin"
...
>
> @@ -250,7 +250,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
> num_pages, param.source != -1 ? FOLL_WRITE : 0, pages);
>
> if (num_pinned != num_pages) {
> - /* get_user_pages() failed */
> + /* get_user_pages_fast() failed */
Let's please just delete that particular comment entirely. It's of
questionable accuracy (partial success is allowed with this API), and it
is echoing the code too closely to be worth the line that it consumes.
More importantly, though, we need to split up the cases of gup_fast
returning a negative value, and a zero or positive value. Either here,
or at "exit:", the negative return case should just skip any attempt to
do any put_page() calls at all. Because it's a maintenance hazard to
leave in a loop that depends on looping from zero, to -ERRNO, and *not*
doing any loops--especially in the signed/unsigned soupy mess around gup
calls.
> pr_debug("fsl-hv: could not lock source buffer\n");
> ret = (num_pinned < 0) ? num_pinned : -EFAULT;
> goto exit;
> @@ -293,12 +293,12 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
>
> exit:
> if (pages) {
> - for (i = 0; i < num_pages; i++)
> - if (pages[i])
> - put_page(pages[i]);
> + for (i = 0; i < num_pinned; i++)
> + put_page(pages[i]);
Looks correct. I sometimes wonder why more callers don't use
release_pages() in situations like this, but that's beyond the scope of
your work here.
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2020-08-31 22:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 22:07 Souptick Joarder
2020-08-31 22:10 ` Souptick Joarder
2020-09-01 0:05 ` John Hubbard
2020-08-31 22:58 ` John Hubbard [this message]
2020-09-01 20:14 ` Souptick Joarder
2020-09-01 20:52 ` John Hubbard
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=82329783-739b-a315-8957-2c49a3ab1350@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=dan.j.williams@intel.com \
--cc=galak@kernel.crashing.org \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@ziepe.ca \
--cc=jrdr.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=timur@freescale.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
all inboxes | Powered by JetHome®