[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yyy8Pp0Y4NRzIzNw@google.com>
Date: Thu, 22 Sep 2022 19:49:18 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: "Wang, Wei W" <wei.w.wang@...el.com>
Cc: Chao Peng <chao.p.peng@...ux.intel.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Jonathan Corbet <corbet@....net>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"x86@...nel.org" <x86@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>, Hugh Dickins <hughd@...gle.com>,
Jeff Layton <jlayton@...nel.org>,
"J . Bruce Fields" <bfields@...ldses.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Shuah Khan <shuah@...nel.org>, Mike Rapoport <rppt@...nel.org>,
Steven Price <steven.price@....com>,
"Maciej S . Szmigiero" <mail@...iej.szmigiero.name>,
Vlastimil Babka <vbabka@...e.cz>,
Vishal Annapurve <vannapurve@...gle.com>,
Yu Zhang <yu.c.zhang@...ux.intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
"Lutomirski, Andy" <luto@...nel.org>,
"Nakajima, Jun" <jun.nakajima@...el.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"david@...hat.com" <david@...hat.com>,
"aarcange@...hat.com" <aarcange@...hat.com>,
"ddutile@...hat.com" <ddutile@...hat.com>,
"dhildenb@...hat.com" <dhildenb@...hat.com>,
Quentin Perret <qperret@...gle.com>,
Michael Roth <michael.roth@....com>,
"Hocko, Michal" <mhocko@...e.com>,
Muchun Song <songmuchun@...edance.com>
Subject: Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd
On Thu, Sep 22, 2022, Wang, Wei W wrote:
> On Thursday, September 15, 2022 10:29 PM, Chao Peng wrote:
> > +int inaccessible_get_pfn(struct file *file, pgoff_t offset, pfn_t *pfn,
> > + int *order)
>
> Better to remove "order" from this interface?
Hard 'no'.
> Some callers only need to get pfn, and no need to bother with
> defining and inputting something unused. For callers who need the "order",
> can easily get it via thp_order(pfn_to_page(pfn)) on their own.
That requires (a) assuming the pfn is backed by struct page, and (b) assuming the
struct page is a transparent huge page. That might be true for the current
implementation, but it most certainly will not always be true.
KVM originally did things like this, where there was dedicated code for THP vs.
HugeTLB, and it was a mess. The goal here is very much to avoid repeating those
mistakes. Have the backing store _tell_ KVM how big the mapping is, don't force
KVM to rediscover the info on its own.
Powered by blists - more mailing lists