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 4D5FBC00140 for ; Wed, 10 Aug 2022 09:45:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF7C98E0002; Wed, 10 Aug 2022 05:45:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA7258E0001; Wed, 10 Aug 2022 05:45:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C962E8E0002; Wed, 10 Aug 2022 05:45:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B93A58E0001 for ; Wed, 10 Aug 2022 05:45:41 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8F3B38113A for ; Wed, 10 Aug 2022 09:45:41 +0000 (UTC) X-FDA: 79783200882.25.52BDABD Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf10.hostedemail.com (Postfix) with ESMTP id C70C4C0175 for ; Wed, 10 Aug 2022 09:45:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660124740; x=1691660740; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=sBavDjNKIFmd2M6Jg3bF8kVDIymkWHMnSEIr5WIN7a0=; b=bi53DbgPOE2OOg7h+nc+qJUVzImMAeU5Bqdpn9P5IctHEeTw5gom4Sqw V4L6pggqE4n9qMxFMjKGdkNj8zvTDWyQtMbBTgnBfa44XdRL3ukwW7V6b rbOXuClV8+6S+azMc21pn+JPLjg+s1TlXgdFYNwxoirhL+7FZ2+ObBPAQ 8AMSqUD1mMPaa4Uzx4/+mxGN8ikgKGxE4dMxO801bU64fMwaoaBaaNBt4 qR3GQ3d/U0tHE1EuEB+5tAdebgp406uwfXGGdt/6b1EicHYesEeLTIKSL JK0D/6ogfmadYyDwV9ofc1IQR07JpzSiCgBY50rveucI/+y5gHA13Vlu3 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10434"; a="288610865" X-IronPort-AV: E=Sophos;i="5.93,227,1654585200"; d="scan'208";a="288610865" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2022 02:45:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,227,1654585200"; d="scan'208";a="601757857" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by orsmga007.jf.intel.com with ESMTP; 10 Aug 2022 02:45:24 -0700 Date: Wed, 10 Aug 2022 17:40:39 +0800 From: Chao Peng To: David Hildenbrand Cc: Paolo Bonzini , 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, linux-kselftest@vger.kernel.org, Jonathan Corbet , Sean Christopherson , 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" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song Subject: Re: [PATCH v7 01/14] mm: Add F_SEAL_AUTO_ALLOCATE seal to memfd Message-ID: <20220810094039.GG862421@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220706082016.2603916-2-chao.p.peng@linux.intel.com> <472207cf-ff71-563b-7b66-0c7bea9ea8ad@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=bi53DbgP; spf=none (imf10.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660124741; a=rsa-sha256; cv=none; b=pUjq4Juy+74Tk/RDwew11JSbcd+s1hDoP8lAtB4jcMpDT2w4hW1HKmnHBvArYrHgtXP1pc wWAZTqsjBw5T4FCYNx0MBlCMm7T70hL+9Z8geemlw0vXIUu4zkYctzFmH1Pda2SicGdocZ baTuYgaR8I5bMST2fnocfFULb+o1kzo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660124741; h=from:from:sender:reply-to: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=EjzxEJvxoy8JFZ5pufQg6fc6HkF7vZ59qB7AYxlYplk=; b=52xHTdfhQyfHbpgUuucmzoMCcPYJLgQEfamNUUAsfruEkZbNhHTOj7IMuIfXHm6FUA6qUu 55i2D+3hl+XpaS6OKH4Z8jHhEX0EcHyfHdjLiEQZgKjQNKT14NSsKRzMecS9RrheWhWPyF guWBqMcbN1TgzQjX0wZfKSMxwgtw9EQ= X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C70C4C0175 X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=bi53DbgP; spf=none (imf10.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Stat-Signature: 6zgenanwng989ekkzczsfec4cwsdrhrm X-HE-Tag: 1660124740-294144 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 Fri, Aug 05, 2022 at 08:06:03PM +0200, David Hildenbrand wrote: > On 05.08.22 19:55, Paolo Bonzini wrote: > > On 7/21/22 11:44, David Hildenbrand wrote: > >> > >> Also, I*think* you can place pages via userfaultfd into shmem. Not > >> sure if that would count "auto alloc", but it would certainly bypass > >> fallocate(). > > > > Yeah, userfaultfd_register would probably have to forbid this for > > F_SEAL_AUTO_ALLOCATE vmas. Maybe the memfile_node can be reused for > > this, adding a new MEMFILE_F_NO_AUTO_ALLOCATE flags? Then > > userfault_register would do something like > > memfile_node_get_flags(vma->vm_file) and check the result. > > An alternative is to simply have the shmem allocation fail in a similar > way. Maybe it does already, I haven't checked (don't think so). This sounds a better option. We don't need uAPI changes for userfault_register uAPI but I guess we will still need a KVM uAPI, either on the memslot or on the whole VM since Roth said this feature should be optional because some usages may want to disable it for performance reason. For details please see discussion: https://lkml.org/lkml/2022/6/23/1905 Chao > > > -- > Thanks, > > David / dhildenb