[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98d35563-8af0-2693-7e76-e6435da0bbee@oracle.com>
Date: Tue, 24 Mar 2020 08:25:09 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Jason Gunthorpe <jgg@...pe.ca>,
"Longpeng (Mike, Cloud Infrastructure Service Product Dept.)"
<longpeng2@...wei.com>
Cc: akpm@...ux-foundation.org, kirill.shutemov@...ux.intel.com,
linux-kernel@...r.kernel.org, arei.gonglei@...wei.com,
weidong.huang@...wei.com, weifuqiang@...wei.com,
kvm@...r.kernel.org, linux-mm@...ck.org,
Matthew Wilcox <willy@...radead.org>,
Sean Christopherson <sean.j.christopherson@...el.com>,
stable@...r.kernel.org
Subject: Re: [PATCH v2] mm/hugetlb: fix a addressing exception caused by
huge_pte_offset()
On 3/24/20 4:55 AM, Jason Gunthorpe wrote:
> Also, since CH moved all the get_user_pages_fast code out of the
> arch's many/all archs can drop their arch specific version of this
> routine. This is really just a specialized version of gup_fast's
> algorithm..
>
> (also the arch versions seem different, why do some return actual
> ptes, not null?)
Not sure I understand that last question. The return value should be
a *pte or null.
/*
* huge_pte_offset() - Walk the page table to resolve the hugepage
* entry at address @addr
*
* Return: Pointer to page table or swap entry (PUD or PMD) for
* address @addr, or NULL if a p*d_none() entry is encountered and the
* size @sz doesn't match the hugepage size at this level of the page
* table.
*/
--
Mike Kravetz
Powered by blists - more mailing lists