Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1572706pxb; Thu, 4 Mar 2021 15:12:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJwvFPfDyXKo6UH0ODqLX9CqWg4FVBTwXJuFODEfR1MTa5PSQVU3KVbew53TAU/yVEhSVRky X-Received: by 2002:a17:906:a443:: with SMTP id cb3mr6576656ejb.542.1614899548379; Thu, 04 Mar 2021 15:12:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614899548; cv=none; d=google.com; s=arc-20160816; b=gjD025r/pedlQo8zivOhyEmjM9XNXV2FO3oxHWvWcpRrcHfqk4wpOnb00ChYI4GHS1 D49Zg0tasvsYgQguWhPHlidbQF9ifoD3oZjZ9w8QHo2whPZ36HgWX4Jjtm8T5L50Y2ri 6l66P3zZOTSXaFI4FAvQJaJNsZTfvhzQJw0c9/n4agdHIC5TSXMcz31kmEf8jFD4WTeY iagZJdBA571Z98nwzQFymbMLfaoGgk+WQOUCWpit0hQN3EvDCjvb4vBms4iYyKLzD8ms iMzU95R+nl1gQxHsZjU0Y3CsD2X7fVq6p153qjOu9yjklJ4AMD8BNrqHExOmh0tcSYts DPXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ythcUjgqINnsei/vh6INsr9vSNU8CUTlpHApMxauUv0=; b=XzXvdbTfWGIOPxtaeazTrz/YVDhvU8jPSSDcWj6mDGEW7vjdyxbYr+SeMCionOtWbP QoxY4TvyYOQzinf2r1Fr8ZxLKxdjDxsln4zL/34ml/+hrBOd2ND3SGCHjzA5d7qoc3fc /JMv5JoDnI4oXMgpdqKRBvu/RNN6fSgccoCxSbk8N1JNVAe/nGqWpFFdquw000DPk/lI cCz4R0HmoZ2uS8t0KrLyvoFb0LyM1Z9+ao14scxbHWopR1u643iL2YJL2c6GzTO7zxkU atu3ipFHxAxTYBTtTC8gtmBBMxTw9wVqRGgN5LOcY0vzsOkNe4gkpVdWMdGyZvORCYz4 pHsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bv10si346212ejb.352.2021.03.04.15.11.38; Thu, 04 Mar 2021 15:12:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383860AbhCCPfX (ORCPT + 99 others); Wed, 3 Mar 2021 10:35:23 -0500 Received: from verein.lst.de ([213.95.11.211]:36166 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356547AbhCCKrm (ORCPT ); Wed, 3 Mar 2021 05:47:42 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 01C4E68C65; Wed, 3 Mar 2021 10:30:53 +0100 (CET) Date: Wed, 3 Mar 2021 10:30:52 +0100 From: Christoph Hellwig To: Shiyang Ruan Cc: linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org, darrick.wong@oracle.com, dan.j.williams@intel.com, willy@infradead.org, jack@suse.cz, viro@zeniv.linux.org.uk, linux-btrfs@vger.kernel.org, ocfs2-devel@oss.oracle.com, david@fromorbit.com, hch@lst.de, rgoldwyn@suse.de, Goldwyn Rodrigues Subject: Re: [PATCH v2 05/10] fsdax: Replace mmap entry in case of CoW Message-ID: <20210303093052.GE12784@lst.de> References: <20210226002030.653855-1-ruansy.fnst@fujitsu.com> <20210226002030.653855-6-ruansy.fnst@fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210226002030.653855-6-ruansy.fnst@fujitsu.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 26, 2021 at 08:20:25AM +0800, Shiyang Ruan wrote: > We replace the existing entry to the newly allocated one in case of CoW. > Also, we mark the entry as PAGECACHE_TAG_TOWRITE so writeback marks this > entry as writeprotected. This helps us snapshots so new write > pagefaults after snapshots trigger a CoW. > > Signed-off-by: Goldwyn Rodrigues > Signed-off-by: Shiyang Ruan > --- > fs/dax.c | 37 ++++++++++++++++++++++++++----------- > 1 file changed, 26 insertions(+), 11 deletions(-) > > diff --git a/fs/dax.c b/fs/dax.c > index 748dfb89fb41..ec4b733e0b59 100644 > --- a/fs/dax.c > +++ b/fs/dax.c > @@ -722,6 +722,9 @@ static int copy_cow_page_dax(struct block_device *bdev, struct dax_device *dax_d > return 0; > } > > +#define DAX_IF_DIRTY (1 << 0) > +#define DAX_IF_COW (1 << 1) > + > /* > * By this point grab_mapping_entry() has ensured that we have a locked entry > * of the appropriate size so we don't have to worry about downgrading PMDs to > @@ -729,16 +732,19 @@ static int copy_cow_page_dax(struct block_device *bdev, struct dax_device *dax_d > * already in the tree, we will skip the insertion and just dirty the PMD as > * appropriate. > */ > -static void *dax_insert_entry(struct xa_state *xas, > - struct address_space *mapping, struct vm_fault *vmf, > - void *entry, pfn_t pfn, unsigned long flags, bool dirty) > +static void *dax_insert_entry(struct xa_state *xas, struct vm_fault *vmf, > + void *entry, pfn_t pfn, unsigned long flags, > + unsigned int insert_flags) > { > + struct address_space *mapping = vmf->vma->vm_file->f_mapping; > void *new_entry = dax_make_entry(pfn, flags); > + bool dirty = insert_flags & DAX_IF_DIRTY; > + bool cow = insert_flags & DAX_IF_COW; > > if (dirty) > __mark_inode_dirty(mapping->host, I_DIRTY_PAGES); I still think the __mark_inode_dirty should just be moved into the one caller that needs it.