Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp5424667rwb; Wed, 17 Aug 2022 17:54:47 -0700 (PDT) X-Google-Smtp-Source: AA6agR6SbmUrmOd21D4gdwTQdlgKMqmjb4w1JD2ufCrSlt9gNMEYEQ6z/CCDNFs1ZmpKIDRPOSgg X-Received: by 2002:a05:6402:43c3:b0:445:db76:de71 with SMTP id p3-20020a05640243c300b00445db76de71mr459872edc.218.1660784087409; Wed, 17 Aug 2022 17:54:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660784087; cv=none; d=google.com; s=arc-20160816; b=oxspznENYkk1/4Da91B8nmhKNXtR1hb4ZlQUSb5btySbXnt7gEChcXmwEcF2z7j6SC /wkIDXGIPe0f1kjJvJ3xt5z4Ytz1O3hbrzuZXZWC9x1g3ytqGKS/AHgmq/DplZKCjT25 rQ4FXz21Cv2d9Hch6aI0JRRpmSwRiuLjwSpCzlOO80GVx4KwcLcc5zyU6DIZ2Hvhh9x2 3lZGoVq9oN0NnkiKF39bNcSXrsLgHLZNtVxMbwE4mT6fjEA7qnvcPnTFkgFKkvx7AYhJ K7QcsiWXgKIrgx0ff8UIgpUCjLur4HjHqr6V/wMe8vLkmVyVyydWyHk/B5ilotDUHX9r WetQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id :dkim-signature:dkim-signature; bh=NIaAYd9poCwuCaReO0KiItjGT5b3278AiQgPlMaoGH8=; b=hJKjIK9AhGMklcDb+tSHlRNBtR/3lQkyriz9fFHLnhxCgT0zEIKXdfT/ifl8QrW02e l/UhVtK0+BAI2dtY4fKQV8EQDNKdaTIPb6W0HgLihQYAQn5XlqFIF6hoxor9LZxlmR3I OG0zEX48E8KxEYwR4k5CdDS1HrYzTMHvgQmnssbdgNgTXv5Dprqfs7i2OCxQ7FP6q843 PlbsZYA2b3ycjP9OXbDC0T9Z+1eHjXgCsMvJX5WFgZA+KbxNpsDPB4D8kdio5F2i88NV KveO9CSEU1x4vOVqXJQbTiZn6YOZzpfyFYvB5//Cd4c48RkcAqR9B7Y6yInxwby6FpWv SsdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov.name header.s=fm2 header.b=PuKLpG0l; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=WGuGDagg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e6-20020a056402190600b0043bd6cf51d1si186285edz.530.2022.08.17.17.54.06; Wed, 17 Aug 2022 17:54:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@shutemov.name header.s=fm2 header.b=PuKLpG0l; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=WGuGDagg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239779AbiHRAUz (ORCPT + 99 others); Wed, 17 Aug 2022 20:20:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231510AbiHRAUw (ORCPT ); Wed, 17 Aug 2022 20:20:52 -0400 X-Greylist: delayed 1199 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 17 Aug 2022 17:20:51 PDT Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E03BEA1D11; Wed, 17 Aug 2022 17:20:51 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 7B68B580556; Wed, 17 Aug 2022 19:41:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 17 Aug 2022 19:41:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1660779685; x=1660786885; bh=NI aAYd9poCwuCaReO0KiItjGT5b3278AiQgPlMaoGH8=; b=PuKLpG0lACFDSWgEO8 rwPWX4M0HQpSuEdYRtGzQptcaolkieS2EgsFIwpoZyncFWpZckNeFIzIIYOqO8zc 9BpZgvlyinTevkQRn/C/ka6JMZsh8Ts9cHQWdeYq9ybnuk1SQZpubaUGZQB9t1lM qk4rSx6j+tUOfRKOd3g94hTTtthwjyy2FqigUkFALmNMXV3xaGruqjoeP5+34xuk J1Cinr4a4qem9KNGhx+lzwXQAr8UJisToeNsfhj8HLQwy0xeOfa5U42VQCIa7k9W qZ8iK9otGm9LKKwttomxp7Dv3pSQF6Et1ZTaIBSz7M8flKM1wmlzQBaAB4PFaBIk k9IQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1660779685; x=1660786885; bh=NIaAYd9poCwuCaReO0KiItjGT5b3 278AiQgPlMaoGH8=; b=WGuGDaggU/a6pga7pL9w3WYTfRF/tux3G1kX0A3mQjNG OC+VxEFGbO+smOA+p7iGMZ3GoMIsMcaWl3/NDeaFMGDz77QMAzUSQkUiUmCGJkRW xHDUodL0TH5AF7G//emEtkunMR0IZ4l2d7XmME00+CIEmSs0g9HkS3qnHI4slsRN HLEINl4PWiLW8DvpQUTe/0aF8/PdVhKDH0qkmMtKQaNXy1O+iZNm5MWAKX+BYowx KuXbnGKaeKu5x2AZgYGthwUdYmgJrzE5cQQyW5v4ZXRMkJgZP9HwjqtkEwDmOL4I VHlt+Z4I/oeTtr+VVKyUXBqBYFKb61xw+pnbo22rNA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehjedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdttddttddtvdenucfhrhhomhepfdfmihhr ihhllhcutedrucfuhhhuthgvmhhovhdfuceokhhirhhilhhlsehshhhuthgvmhhovhdrnh grmhgvqeenucggtffrrghtthgvrhhnpefhieeghfdtfeehtdeftdehgfehuddtvdeuheet tddtheejueekjeegueeivdektdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehkihhrihhllhesshhhuhhtvghmohhvrdhnrghmvg X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 17 Aug 2022 19:41:23 -0400 (EDT) Received: by box.shutemov.name (Postfix, from userid 1000) id E5075104A77; Thu, 18 Aug 2022 02:41:20 +0300 (+03) Date: Thu, 18 Aug 2022 02:41:20 +0300 From: "Kirill A. Shutemov" To: Paolo Bonzini Cc: David Hildenbrand , 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, 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: <20220817234120.mw2j3cgshmuyo2vw@box.shutemov.name> 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: <472207cf-ff71-563b-7b66-0c7bea9ea8ad@redhat.com> X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 05, 2022 at 07:55:38PM +0200, 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. I donno, memory allocation with userfaultfd looks pretty intentional to me. Why would F_SEAL_AUTO_ALLOCATE prevent it? Maybe we would need it in the future for post-copy migration or something? Or existing practises around userfaultfd touch memory randomly and therefore incompatible with F_SEAL_AUTO_ALLOCATE intent? Note, that userfaultfd is only relevant for shared memory as it requires VMA which we don't have for MFD_INACCESSIBLE. -- Kiryl Shutsemau / Kirill A. Shutemov