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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A54CAECAAD8 for ; Fri, 23 Sep 2022 00:53:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B6F194000A; Thu, 22 Sep 2022 20:53:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 066D8940007; Thu, 22 Sep 2022 20:53:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E225694000A; Thu, 22 Sep 2022 20:53:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id CCAA3940007 for ; Thu, 22 Sep 2022 20:53:33 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 98F00160940 for ; Fri, 23 Sep 2022 00:53:33 +0000 (UTC) X-FDA: 79941527106.12.AA1ECE2 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf31.hostedemail.com (Postfix) with ESMTP id E928320008 for ; Fri, 23 Sep 2022 00:53:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663894413; x=1695430413; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=N5ROSjhMMMcLpyjlHpJbtQYkQW/pwctSUSnQMueHIwE=; b=Nr0Jfj41OfojPkzP7M62OsIVIFVrcB3uqZR8wFr/+k8CZEK2S7Jy3Q7a 6u35haiaIT3XRf3qyq/MmCv1HEk96WzVN/x6EqW+u6S+cvTAg4vwwsHEd sWjUVWp5/JorJJkdanEb2Py1wQyJ8JsarzO/ii1Wc4B+3qXbe6L2aaFQp aeEnCAjEZF2OvN6hOdtBNHxTaL4iGO+F+tvPNqxnU2hrMPTLkSZxSyR/h vibHFEC3sDKtoZlj5SgMv3vuhgezrNlZXB42/kp2jrl0iLUAKrQeQdNk3 Al9Sn1+vEVBlHiFiOnJqfRK7qIkvFYN6kIGdDWxPI19eouFRIknbaoJyI g==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="386764063" X-IronPort-AV: E=Sophos;i="5.93,337,1654585200"; d="scan'208";a="386764063" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 17:53:31 -0700 X-IronPort-AV: E=Sophos;i="5.93,337,1654585200"; d="scan'208";a="622334850" Received: from dnessim-mobl1.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.60.183]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 17:53:21 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 6B9DA104532; Fri, 23 Sep 2022 03:53:19 +0300 (+03) Date: Fri, 23 Sep 2022 03:53:19 +0300 From: "Kirill A . Shutemov" To: Sean Christopherson Cc: "Wang, Wei W" , 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 , "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: <20220923005319.wkzpl36uailh4zbw@box.shutemov.name> 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: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663894413; a=rsa-sha256; cv=none; b=GhwLLqSMaUycWK15lunzw+Kde4Om9G5MQEVeHoSoXbno5AloPWrGrVkA1UjEwc2ankATwQ mfAC+9AB6jjTdUAqE9lXOuYibJ0njOHnJqB7l658QfOOGNHfMobziZhDHfqOsTqsTwkseT fWPa+ZU6C/ddCi3aw+qveY60XKo8rGE= ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Nr0Jfj41; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf31.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663894413; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2D/rxUUceEPhNIhpe4F0FMu/oIZ5DayhRhMwIXtL/nQ=; b=tFUFgQppaPTtFxwmGUqrbOaEEPurVse4hocUHEvD4AcfdXL9O4Al9fZN8HA73D6+Bpsauz 6tW+o41rnjXulWYb8Vm0HnQ5XpECVzs3RLuwAd+QYeXTWJTg7PYa34t+LWZzTpEGfpMHqN 5PsKC+HmcFl1z0eLtWjf/UZqgFMytQU= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E928320008 X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Nr0Jfj41; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf31.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=kirill.shutemov@linux.intel.com X-Stat-Signature: 4d86167aqih94ozxczcgzeapt4jwybfh X-HE-Tag: 1663894412-775043 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Sep 22, 2022 at 07:49:18PM +0000, Sean Christopherson wrote: > 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. I guess we can allow order pointer to be NULL to cover caller that don't need to know the order. Is it useful? -- Kiryl Shutsemau / Kirill A. Shutemov