From: John Hubbard <jhubbard@nvidia.com>
To: Ira Weiny <ira.weiny@intel.com>, Artemy Kovalyov <artemyko@mellanox.com>
Cc: "john.hubbard@gmail.com" <john.hubbard@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
Doug Ledford <dledford@redhat.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH v2] RDMA/umem: minor bug fix and cleanup in error handling paths
Date: Mon, 4 Mar 2019 15:11:05 -0800 [thread overview]
Message-ID: <bef8680b-acc5-9f13-f49e-8f36f1939387@nvidia.com> (raw)
In-Reply-To: <20190303165550.GB27123@iweiny-DESK2.sc.intel.com>
On 3/3/19 8:55 AM, Ira Weiny wrote:
> On Sun, Mar 03, 2019 at 11:52:41AM +0200, Artemy Kovalyov wrote:
>>
>>
>> On 02/03/2019 21:44, Ira Weiny wrote:
>>>
>>> On Sat, Mar 02, 2019 at 12:24:35PM -0800, john.hubbard@gmail.com wrote:
>>>> From: John Hubbard <jhubbard@nvidia.com>
>>>>
>>>> ...
>>>> 3. Dead code removal: the check for (user_virt & ~page_mask)
>>>> is checking for a condition that can never happen,
>>>> because earlier:
>>>>
>>>> user_virt = user_virt & page_mask;
>>>>
>>>> ...so, remove that entire phrase.
>>>>
>>>> bcnt -= min_t(size_t, npages << PAGE_SHIFT, bcnt);
>>>> mutex_lock(&umem_odp->umem_mutex);
>>>> for (j = 0; j < npages; j++, user_virt += PAGE_SIZE) {
>>>> - if (user_virt & ~page_mask) {
>>>> - p += PAGE_SIZE;
>>>> - if (page_to_phys(local_page_list[j]) != p) {
>>>> - ret = -EFAULT;
>>>> - break;
>>>> - }
>>>> - put_page(local_page_list[j]);
>>>> - continue;
>>>> - }
>>>> -
>>>
>>> I think this is trying to account for compound pages. (ie page_mask could
>>> represent more than PAGE_SIZE which is what user_virt is being incrimented by.)
>>> But putting the page in that case seems to be the wrong thing to do?
>>>
>>> Yes this was added by Artemy[1] now cc'ed.
>>
>> Right, this is for huge pages, please keep it.
>> put_page() needed to decrement refcount of the head page.
>
> You mean decrement the refcount of the _non_-head pages?
>
> Ira
>
Actually, I'm sure Artemy means head page, because put_page() always
operates on the head page.
And this reminds me that I have a problem to solve nearby: get_user_pages
on huge pages increments the page->_refcount *for each tail page* as well.
That's a minor problem for my put_user_page()
patchset, because my approach so far assumed that I could just change us
over to:
get_user_page(): increments page->_refcount by a large amount (1024)
put_user_page(): decrements page->_refcount by a large amount (1024)
...and just stop doing the odd (to me) technique of incrementing once for
each tail page. I cannot see any reason why that's actually required, as
opposed to just "raise the page->_refcount enough to avoid losing the head
page too soon".
However, it may be tricky to do this in one pass. Probably at first, I'll have
to do this horrible thing approach:
get_user_page(): increments page->_refcount by a large amount (1024)
put_user_page(): decrements page->_refcount by a large amount (1024) MULTIPLIED
by the number of tail pages. argghhh that's ugly.
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2019-03-04 23:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-02 3:27 [PATCH 0/1] " john.hubbard
2019-03-02 3:27 ` [PATCH] " john.hubbard
2019-03-02 16:03 ` kbuild test robot
2019-03-02 16:14 ` kbuild test robot
2019-03-02 20:24 ` [PATCH v2] " john.hubbard
2019-03-02 19:44 ` Ira Weiny
2019-03-03 9:52 ` Artemy Kovalyov
2019-03-03 16:55 ` Ira Weiny
2019-03-04 23:11 ` John Hubbard [this message]
2019-03-04 20:13 ` Ira Weiny
2019-03-05 20:10 ` John Hubbard
2019-03-04 23:36 ` John Hubbard
2019-03-05 0:53 ` Jason Gunthorpe
2019-03-03 22:37 ` John Hubbard
2019-03-04 6:44 ` Leon Romanovsky
2019-03-06 1:02 ` Artemy Kovalyov
2019-03-06 1:32 ` Jason Gunthorpe
2019-03-06 1:34 ` John Hubbard
2019-03-06 1:37 ` John Hubbard
2019-03-06 1:51 ` Jason Gunthorpe
2019-03-06 2:04 ` 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=bef8680b-acc5-9f13-f49e-8f36f1939387@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=artemyko@mellanox.com \
--cc=dledford@redhat.com \
--cc=ira.weiny@intel.com \
--cc=jgg@ziepe.ca \
--cc=john.hubbard@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@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