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 BF760C433F5 for ; Fri, 11 Mar 2022 08:42:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3080F8D0002; Fri, 11 Mar 2022 03:42:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B5FB8D0001; Fri, 11 Mar 2022 03:42:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A5038D0002; Fri, 11 Mar 2022 03:42:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 0B8E58D0001 for ; Fri, 11 Mar 2022 03:42:37 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id D9CD0121097 for ; Fri, 11 Mar 2022 08:42:36 +0000 (UTC) X-FDA: 79231464312.05.8959FA0 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf20.hostedemail.com (Postfix) with ESMTP id AC06C1C0015 for ; Fri, 11 Mar 2022 08:42:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646988155; x=1678524155; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=rnnCy0Hbi4uhBKWJV93SLPhz7c/vwnMymNdqjK9CGiI=; b=miqjQIXSg7SBUVK1bladzPXtFnsYMGTfCeW/IGf8ddiKkxw6YS7i6rQe ebbu9NljOQ1mCMyOHjUqDi8UQaMDyA4ajI/0dLykmDLGEfGUAUXnezG/g xvQpr9XeM9Cy1ksiGX7q1Gtysrvkrl0XVL1HmZqendsN1aVNMWj3oa2II OQKxYV0iVNqVeAZ9p6u5YMQrwqAQhTItOctv2XTiO8cvz/5aLI8qS27cL 5wIfd/NA+mkXmtSc/IFUp6zTAM430ThB9Vt6BeVNEJL3EM1b9KYo6+L2o j65s9K3kc7YvPi5dD9Gc5exRO3X7yTBm7xSN2brCUPODJVymoka6QHEpO Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10282"; a="254357826" X-IronPort-AV: E=Sophos;i="5.90,173,1643702400"; d="scan'208";a="254357826" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2022 00:42:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,173,1643702400"; d="scan'208";a="538926645" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.101]) by orsmga007.jf.intel.com with ESMTP; 11 Mar 2022 00:42:24 -0800 Date: Fri, 11 Mar 2022 16:42:08 +0800 From: Chao Peng To: Dave Chinner Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , 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 , 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, david@redhat.com Subject: Re: [PATCH v5 03/13] mm/shmem: Support memfile_notifier Message-ID: <20220311084208.GB56193@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220310140911.50924-1-chao.p.peng@linux.intel.com> <20220310140911.50924-4-chao.p.peng@linux.intel.com> <20220310230822.GO661808@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220310230822.GO661808@dread.disaster.area> User-Agent: Mutt/1.9.4 (2018-02-28) X-Stat-Signature: 3jhtwiadmpscsa9dddoht1hdy4asbph3 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=miqjQIXS; spf=none (imf20.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: AC06C1C0015 X-HE-Tag: 1646988155-353330 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, Mar 11, 2022 at 10:08:22AM +1100, Dave Chinner wrote: > On Thu, Mar 10, 2022 at 10:09:01PM +0800, Chao Peng wrote: > > From: "Kirill A. Shutemov" > > > > It maintains a memfile_notifier list in shmem_inode_info structure and > > implements memfile_pfn_ops callbacks defined by memfile_notifier. It > > then exposes them to memfile_notifier via > > shmem_get_memfile_notifier_info. > > > > We use SGP_NOALLOC in shmem_get_lock_pfn since the pages should be > > allocated by userspace for private memory. If there is no pages > > allocated at the offset then error should be returned so KVM knows that > > the memory is not private memory. > > > > Signed-off-by: Kirill A. Shutemov > > Signed-off-by: Chao Peng > > --- > > include/linux/shmem_fs.h | 4 +++ > > mm/shmem.c | 76 ++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 80 insertions(+) > > > > diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h > > index 2dde843f28ef..7bb16f2d2825 100644 > > --- a/include/linux/shmem_fs.h > > +++ b/include/linux/shmem_fs.h > > @@ -9,6 +9,7 @@ > > #include > > #include > > #include > > +#include > > > > /* inode in-kernel data */ > > > > @@ -28,6 +29,9 @@ struct shmem_inode_info { > > struct simple_xattrs xattrs; /* list of xattrs */ > > atomic_t stop_eviction; /* hold when working on inode */ > > unsigned int xflags; /* shmem extended flags */ > > +#ifdef CONFIG_MEMFILE_NOTIFIER > > + struct memfile_notifier_list memfile_notifiers; > > +#endif > > struct inode vfs_inode; > > }; > > > > diff --git a/mm/shmem.c b/mm/shmem.c > > index 9b31a7056009..7b43e274c9a2 100644 > > --- a/mm/shmem.c > > +++ b/mm/shmem.c > > @@ -903,6 +903,28 @@ static struct folio *shmem_get_partial_folio(struct inode *inode, pgoff_t index) > > return page ? page_folio(page) : NULL; > > } > > > > +static void notify_fallocate(struct inode *inode, pgoff_t start, pgoff_t end) > > +{ > > +#ifdef CONFIG_MEMFILE_NOTIFIER > > + struct shmem_inode_info *info = SHMEM_I(inode); > > + > > + memfile_notifier_fallocate(&info->memfile_notifiers, start, end); > > +#endif > > +} > > *notify_populate(), not fallocate. This is a notification that a > range has been populated, not that the fallocate() syscall was run > to populate the backing store of a file. > > i.e. fallocate is the name of a userspace filesystem API that can > be used to manipulate the backing store of a file in various ways. > It can both populate and punch away the backing store of a file, and > some operations that fallocate() can run will do both (e.g. > FALLOC_FL_ZERO_RANGE) and so could generate both > notify_invalidate() and a notify_populate() events. Yes, I fully agreed fallocate syscall has both populating and hole punching semantics so notify_fallocate can be misleading since we actually mean populate here. > > Hence "fallocate" as an internal mm namespace or operation does not > belong anywhere in core MM infrastructure - it should never get used > anywhere other than the VFS/filesystem layers that implement the > fallocate() syscall or use it directly. Will use your suggestion through the series where applied. Thanks for your suggestion. Chao > > Cheers, > > Dave. > > -- > Dave Chinner > david@fromorbit.com