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 2B7ADC00140 for ; Wed, 10 Aug 2022 09:45:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231364AbiHJJpu (ORCPT ); Wed, 10 Aug 2022 05:45:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232260AbiHJJpi (ORCPT ); Wed, 10 Aug 2022 05:45:38 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09D951EAC3; Wed, 10 Aug 2022 02:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660124736; x=1691660736; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=sBavDjNKIFmd2M6Jg3bF8kVDIymkWHMnSEIr5WIN7a0=; b=O61/zh9nP1a3NA1MGvroQMtaoN5BFj12Ro1Ly3C9SI+LvvDmhryVaJP2 CarjfMhP3S2UW8pzfkIzHQX/EkG31FdTc3R+Z8xx694dCplk3YqpOQW4J 4WWBMeqVCVSOCG3IamVhM36kB761utc/Eer6Jp+NQnCZQQgSmJjmdq2tE iGeMt5wqLmDfQmRA9jFKLpQWvtmhDKxRUQ3ccKTlRnEtmlKtecqbp02H0 SMKVZ70THXKKgFwj59jC7+QeIllAUc1U5rVeufdEZF4WAN9e2j7WGo8k7 T/jngFph2gS8+E4vFHrqNbjcS6s1SxTCjT7ssgLMSPRW1UlzIpUY8TH5n w==; X-IronPort-AV: E=McAfee;i="6400,9594,10434"; a="277983040" X-IronPort-AV: E=Sophos;i="5.93,227,1654585200"; d="scan'208";a="277983040" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2022 02:45:35 -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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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