From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DF2BECAAD8 for ; Thu, 22 Sep 2022 19:49:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231990AbiIVTt0 (ORCPT ); Thu, 22 Sep 2022 15:49:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231761AbiIVTtX (ORCPT ); Thu, 22 Sep 2022 15:49:23 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6AB510B5B6 for ; Thu, 22 Sep 2022 12:49:22 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id i15-20020a17090a4b8f00b0020073b4ac27so3257897pjh.3 for ; Thu, 22 Sep 2022 12:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=AOIMXA4PI9BYXrk6/Ja2mOKlrFIROrj5K/ieUQQwXS4=; b=h1quGJbzNcYbvksztMmJbAj4021+BcmdngI9oVLKqryAXjZOZrGY+bZOFcLzMWlozZ LAcA23Adi1Jic4pRnJCptlWTG4EcoRJkXHfvedp0K1HaJOCXyEXxuhzgdof/jPIDOZEe ebqjyLF5ANcpzYiinKi6eaQnqth3W4n2V8+InjN4EWNaK7npJ/bYc7FhRS+iyNb4HHPb Efk7QXZ7wTcSNyFHTH7NWGDPMQ4YLD125sVU1j3HVB2TkIAvgthLngw1wMrAfORH5ZfR U8+tmRxUsuSWAVFhBHQcUHbhvue7DyoPTDpJKMkc7xktoeaZV8RiJlYUMocHTDHlXZyf XJ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=AOIMXA4PI9BYXrk6/Ja2mOKlrFIROrj5K/ieUQQwXS4=; b=t0StpSONQfLcoSMJaK5PIMngCOHW800072i2HfFo34igxiE35hTLkvmW2t6n3k/M3f BbVPljbkMH5UynsmcNVV7nWoKxalCr8o6uvC98D82DTIAhWVXj9Mdsd/rSu/0OrHKFRB 8BaHmlAyvSc/f8ujF+YHcXjGgNJDS22TUyQIHlFx1uDu6+tswvTrJCKKUb5uldZdMl4p Ns5x1YZay2T309DCLuga5bHdUx5NZXIevEXPegN9Hu8M6O1CO0ytDnyXr50A4+C7hCJn zuIs2RGiV7dcu00geDmuOBA4Y/bRVRWdk97hnfm0duli3eUbFzf1K94IWCEY70ffvgmr y9pg== X-Gm-Message-State: ACrzQf2ccGJI+Z0bC3/8fzqL8tL4DC8WMQNG+fxCVLMuR3tMQpgneeyG pAtbqcD4rhhBYQZa5b/nZe/SNw== X-Google-Smtp-Source: AMsMyM7xkIpUg/GEtYg3CdJDso/M2NS+vljJqn+Iz/Og0ecRlPYRkH7bufKUsfNRGuIjAMJq7OVhXg== X-Received: by 2002:a17:90a:644e:b0:200:422c:6b1 with SMTP id y14-20020a17090a644e00b00200422c06b1mr5394594pjm.183.1663876162098; Thu, 22 Sep 2022 12:49:22 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id a10-20020a170902ecca00b00172897952a0sm4576315plh.283.2022.09.22.12.49.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Sep 2022 12:49:21 -0700 (PDT) Date: Thu, 22 Sep 2022 19:49:18 +0000 From: Sean Christopherson To: "Wang, Wei W" Cc: Chao Peng , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" , "linux-api@vger.kernel.org" , "linux-doc@vger.kernel.org" , "qemu-devel@nongnu.org" , Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , "Lutomirski, Andy" , "Nakajima, Jun" , "Hansen, Dave" , "ak@linux.intel.com" , "david@redhat.com" , "aarcange@redhat.com" , "ddutile@redhat.com" , "dhildenb@redhat.com" , Quentin Perret , Michael Roth , "Hocko, Michal" , Muchun Song Subject: Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd Message-ID: References: <20220915142913.2213336-1-chao.p.peng@linux.intel.com> <20220915142913.2213336-2-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.