linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Alistair Popple <apopple@nvidia.com>, <akpm@linux-foundation.org>,
	<dan.j.williams@intel.com>, <linux-mm@kvack.org>
Cc: <alison.schofield@intel.com>,
	Alistair Popple <apopple@nvidia.com>, <lina@asahilina.net>,
	<zhang.lyra@gmail.com>, <gerald.schaefer@linux.ibm.com>,
	<vishal.l.verma@intel.com>, <dave.jiang@intel.com>,
	<logang@deltatee.com>, <bhelgaas@google.com>, <jack@suse.cz>,
	<jgg@ziepe.ca>, <catalin.marinas@arm.com>, <will@kernel.org>,
	<mpe@ellerman.id.au>, <npiggin@gmail.com>,
	<dave.hansen@linux.intel.com>, <ira.weiny@intel.com>,
	<willy@infradead.org>, <djwong@kernel.org>, <tytso@mit.edu>,
	<linmiaohe@huawei.com>, <david@redhat.com>, <peterx@redhat.com>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linuxppc-dev@lists.ozlabs.org>, <nvdimm@lists.linux.dev>,
	<linux-cxl@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-ext4@vger.kernel.org>, <linux-xfs@vger.kernel.org>,
	<jhubbard@nvidia.com>, <hch@lst.de>, <david@fromorbit.com>,
	<chenhuacai@kernel.org>, <kernel@xen0n.name>,
	<loongarch@lists.linux.dev>
Subject: Re: [PATCH v6 06/26] fs/dax: Always remove DAX page-cache entries when breaking layouts
Date: Mon, 13 Jan 2025 15:31:57 -0800	[thread overview]
Message-ID: <6785a26d48c86_20fa294d8@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <47bef43b54474a8ba7f266b9b5fc68ed91b1d7b8.1736488799.git-series.apopple@nvidia.com>

Alistair Popple wrote:
> Prior to any truncation operations file systems call
> dax_break_mapping() to ensure pages in the range are not under going
> DMA. Later DAX page-cache entries will be removed by
> truncate_folio_batch_exceptionals() in the generic page-cache code.
> 
> However this makes it possible for folios to be removed from the
> page-cache even though they are still DMA busy if the file-system
> hasn't called dax_break_mapping(). It also means they can never be
> waited on in future because FS DAX will lose track of them once the
> page-cache entry has been deleted.
> 
> Instead it is better to delete the FS DAX entry when the file-system
> calls dax_break_mapping() as part of it's truncate operation. This
> ensures only idle pages can be removed from the FS DAX page-cache and
> makes it easy to detect if a file-system hasn't called
> dax_break_mapping() prior to a truncate operation.
> 
> Signed-off-by: Alistair Popple <apopple@nvidia.com>
> 
> ---
> 
> Ideally I think we would move the whole wait-for-idle logic directly
> into the truncate paths. However this is difficult for a few
> reasons. Each filesystem needs it's own wait callback, although a new
> address space operation could address that. More problematic is that
> the wait-for-idle can fail as the wait is TASK_INTERRUPTIBLE, but none
> of the generic truncate paths allow for failure.
> 
> So it ends up being easier to continue to let file systems call this
> and check that they behave as expected.
> ---
>  fs/dax.c            | 33 +++++++++++++++++++++++++++++++++
>  fs/xfs/xfs_inode.c  |  6 ++++++
>  include/linux/dax.h |  2 ++
>  mm/truncate.c       | 16 +++++++++++++++-
>  4 files changed, 56 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index 9c3bd07..7008a73 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -845,6 +845,36 @@ int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index)
>  	return ret;
>  }
>  
> +void dax_delete_mapping_range(struct address_space *mapping,
> +				loff_t start, loff_t end)
> +{
> +	void *entry;
> +	pgoff_t start_idx = start >> PAGE_SHIFT;
> +	pgoff_t end_idx;
> +	XA_STATE(xas, &mapping->i_pages, start_idx);
> +
> +	/* If end == LLONG_MAX, all pages from start to till end of file */
> +	if (end == LLONG_MAX)
> +		end_idx = ULONG_MAX;
> +	else
> +		end_idx = end >> PAGE_SHIFT;
> +
> +	xas_lock_irq(&xas);
> +	xas_for_each(&xas, entry, end_idx) {
> +		if (!xa_is_value(entry))
> +			continue;
> +		entry = wait_entry_unlocked_exclusive(&xas, entry);
> +		if (!entry)
> +			continue;
> +		dax_disassociate_entry(entry, mapping, true);
> +		xas_store(&xas, NULL);
> +		mapping->nrpages -= 1UL << dax_entry_order(entry);
> +		put_unlocked_entry(&xas, entry, WAKE_ALL);
> +	}
> +	xas_unlock_irq(&xas);
> +}
> +EXPORT_SYMBOL_GPL(dax_delete_mapping_range);
> +
>  static int wait_page_idle(struct page *page,
>  			void (cb)(struct inode *),
>  			struct inode *inode)
> @@ -874,6 +904,9 @@ int dax_break_mapping(struct inode *inode, loff_t start, loff_t end,
>  		error = wait_page_idle(page, cb, inode);
>  	} while (error == 0);
>  
> +	if (!page)
> +		dax_delete_mapping_range(inode->i_mapping, start, end);
> +

Just reinforcing the rename comment on the last patch...

I think this is an example where the
s/dax_break_mapping/dax_break_layout/ rename helps disambiguate what is
related to mapping cleanup and what is related to mapping cleanup as
dax_break_layout calls dax_delete_mapping.

>  	return error;
>  }
>  EXPORT_SYMBOL_GPL(dax_break_mapping);
> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> index 295730a..4410b42 100644
> --- a/fs/xfs/xfs_inode.c
> +++ b/fs/xfs/xfs_inode.c
> @@ -2746,6 +2746,12 @@ xfs_mmaplock_two_inodes_and_break_dax_layout(
>  		goto again;
>  	}
>  
> +	/*
> +	 * Normally xfs_break_dax_layouts() would delete the mapping entries as well so
> +	 * do that here.
> +	 */
> +	dax_delete_mapping_range(VFS_I(ip2)->i_mapping, 0, LLONG_MAX);
> +

I think it is unfortunate that dax_break_mapping is so close to being
useful for this case... how about this incremental cleanup?

diff --git a/fs/dax.c b/fs/dax.c
index facddd6c6bbb..1fa5521e5a2e 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -942,12 +942,15 @@ static void wait_page_idle_uninterruptible(struct page *page,
 /*
  * Unmaps the inode and waits for any DMA to complete prior to deleting the
  * DAX mapping entries for the range.
+ *
+ * For NOWAIT behavior, pass @cb as NULL to early-exit on first found
+ * busy page
  */
 int dax_break_mapping(struct inode *inode, loff_t start, loff_t end,
 		void (cb)(struct inode *))
 {
 	struct page *page;
-	int error;
+	int error = 0;
 
 	if (!dax_mapping(inode->i_mapping))
 		return 0;
@@ -956,6 +959,10 @@ int dax_break_mapping(struct inode *inode, loff_t start, loff_t end,
 		page = dax_layout_busy_page_range(inode->i_mapping, start, end);
 		if (!page)
 			break;
+		if (!cb) {
+			error = -ERESTARTSYS;
+			break;
+		}
 
 		error = wait_page_idle(page, cb, inode);
 	} while (error == 0);
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 7bfb4eb387c6..0988a9088259 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2739,19 +2739,13 @@ xfs_mmaplock_two_inodes_and_break_dax_layout(
 	 * need to unlock & lock the XFS_MMAPLOCK_EXCL which is not suitable
 	 * for this nested lock case.
 	 */
-	page = dax_layout_busy_page(VFS_I(ip2)->i_mapping);
-	if (page && page_ref_count(page) != 0) {
+	error = dax_break_layout(VFS_I(ip2), 0, -1, NULL);
+	if (error) {
 		xfs_iunlock(ip2, XFS_MMAPLOCK_EXCL);
 		xfs_iunlock(ip1, XFS_MMAPLOCK_EXCL);
 		goto again;
 	}
 
-	/*
-	 * Normally xfs_break_dax_layouts() would delete the mapping entries as well so
-	 * do that here.
-	 */
-	dax_delete_mapping_range(VFS_I(ip2)->i_mapping, 0, LLONG_MAX);
-
 	return 0;
 }
 

This also addresses Darrick's feedback around introducing
dax_page_in_use() which xfs does not really care about, only that no
more pages are busy.

>  	return 0;
>  }
>  
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index f6583d3..ef9e02c 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -263,6 +263,8 @@ vm_fault_t dax_iomap_fault(struct vm_fault *vmf, unsigned int order,
>  vm_fault_t dax_finish_sync_fault(struct vm_fault *vmf,
>  		unsigned int order, pfn_t pfn);
>  int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index);
> +void dax_delete_mapping_range(struct address_space *mapping,
> +				loff_t start, loff_t end);
>  int dax_invalidate_mapping_entry_sync(struct address_space *mapping,
>  				      pgoff_t index);
>  int __must_check dax_break_mapping(struct inode *inode, loff_t start,
> diff --git a/mm/truncate.c b/mm/truncate.c
> index 7c304d2..b7f51a6 100644
> --- a/mm/truncate.c
> +++ b/mm/truncate.c
> @@ -78,8 +78,22 @@ static void truncate_folio_batch_exceptionals(struct address_space *mapping,
>  
>  	if (dax_mapping(mapping)) {
>  		for (i = j; i < nr; i++) {
> -			if (xa_is_value(fbatch->folios[i]))
> +			if (xa_is_value(fbatch->folios[i])) {
> +				/*
> +				 * File systems should already have called
> +				 * dax_break_mapping_entry() to remove all DAX
> +				 * entries while holding a lock to prevent
> +				 * establishing new entries. Therefore we
> +				 * shouldn't find any here.
> +				 */
> +				WARN_ON_ONCE(1);
> +
> +				/*
> +				 * Delete the mapping so truncate_pagecache()
> +				 * doesn't loop forever.
> +				 */
>  				dax_delete_mapping_entry(mapping, indices[i]);
> +			}

Looks good.

With the above additional fixup you can add:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>


  reply	other threads:[~2025-01-13 23:34 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10  6:00 [PATCH v6 00/26] fs/dax: Fix ZONE_DEVICE page reference counts Alistair Popple
2025-01-10  6:00 ` [PATCH v6 01/26] fuse: Fix dax truncate/punch_hole fault path Alistair Popple
2025-02-05 13:03   ` Vivek Goyal
2025-02-06  0:10     ` Dan Williams
2025-02-06 12:41       ` Asahi Lina
2025-02-06 19:44         ` Dan Williams
2025-02-06 19:57           ` Asahi Lina
2025-02-06 13:37       ` Vivek Goyal
2025-02-06 14:30         ` Stefan Hajnoczi
2025-02-06 14:59           ` Albert Esteve
2025-02-06 18:10             ` Stefan Hajnoczi
2025-02-06 18:22             ` David Hildenbrand
2025-02-07 16:16               ` Albert Esteve
2025-01-10  6:00 ` [PATCH v6 02/26] fs/dax: Return unmapped busy pages from dax_layout_busy_page_range() Alistair Popple
2025-01-10  6:00 ` [PATCH v6 03/26] fs/dax: Don't skip locked entries when scanning entries Alistair Popple
2025-01-10  6:00 ` [PATCH v6 04/26] fs/dax: Refactor wait for dax idle page Alistair Popple
2025-01-10  6:00 ` [PATCH v6 05/26] fs/dax: Create a common implementation to break DAX layouts Alistair Popple
2025-01-10 16:44   ` Darrick J. Wong
2025-01-13  0:47     ` Alistair Popple
2025-01-13  2:47       ` Darrick J. Wong
2025-01-13 20:11   ` Dan Williams
2025-01-13 23:06   ` Dan Williams
2025-01-14  0:19   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 06/26] fs/dax: Always remove DAX page-cache entries when breaking layouts Alistair Popple
2025-01-13 23:31   ` Dan Williams [this message]
2025-01-10  6:00 ` [PATCH v6 07/26] fs/dax: Ensure all pages are idle prior to filesystem unmount Alistair Popple
2025-01-10 16:50   ` Darrick J. Wong
2025-01-13  0:57     ` Alistair Popple
2025-01-13  2:49       ` Darrick J. Wong
2025-01-13  5:48         ` Alistair Popple
2025-01-13 16:39           ` Darrick J. Wong
2025-01-13 23:42   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 08/26] fs/dax: Remove PAGE_MAPPING_DAX_SHARED mapping flag Alistair Popple
2025-01-14  0:52   ` Dan Williams
2025-01-15  5:32     ` Alistair Popple
2025-01-15  5:44       ` Dan Williams
2025-01-17  0:54         ` Alistair Popple
2025-01-14 14:47   ` David Hildenbrand
2025-01-10  6:00 ` [PATCH v6 09/26] mm/gup: Remove redundant check for PCI P2PDMA page Alistair Popple
2025-01-10  6:00 ` [PATCH v6 10/26] mm/mm_init: Move p2pdma page refcount initialisation to p2pdma Alistair Popple
2025-01-14 14:51   ` David Hildenbrand
2025-01-10  6:00 ` [PATCH v6 11/26] mm: Allow compound zone device pages Alistair Popple
2025-01-14 14:59   ` David Hildenbrand
2025-01-17  1:05     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 12/26] mm/memory: Enhance insert_page_into_pte_locked() to create writable mappings Alistair Popple
2025-01-14 15:03   ` David Hildenbrand
     [not found]   ` <6785b90f300d8_20fa29465@dwillia2-xfh.jf.intel.com.notmuch>
2025-01-15  5:36     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 13/26] mm/memory: Add vmf_insert_page_mkwrite() Alistair Popple
2025-01-14 16:15   ` David Hildenbrand
2025-01-15  6:13     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 14/26] rmap: Add support for PUD sized mappings to rmap Alistair Popple
2025-01-14  1:21   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 15/26] huge_memory: Add vmf_insert_folio_pud() Alistair Popple
2025-01-14  1:27   ` Dan Williams
2025-01-14 16:22   ` David Hildenbrand
2025-01-15  6:38     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 16/26] huge_memory: Add vmf_insert_folio_pmd() Alistair Popple
2025-01-14  2:04   ` Dan Williams
2025-01-14 16:40   ` David Hildenbrand
2025-01-14 17:22     ` Dan Williams
2025-01-15  7:05       ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 17/26] memremap: Add is_devdax_page() and is_fsdax_page() helpers Alistair Popple
2025-01-14  2:05   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 18/26] mm/gup: Don't allow FOLL_LONGTERM pinning of FS DAX pages Alistair Popple
2025-01-14  2:16   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 19/26] proc/task_mmu: Mark devdax and fsdax pages as always unpinned Alistair Popple
2025-01-14  2:28   ` Dan Williams
2025-01-14 16:45     ` David Hildenbrand
2025-01-17  1:28       ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 20/26] mm/mlock: Skip ZONE_DEVICE PMDs during mlock Alistair Popple
2025-01-14  2:42   ` Dan Williams
2025-01-17  1:54     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 21/26] fs/dax: Properly refcount fs dax pages Alistair Popple
2025-01-10 16:54   ` Darrick J. Wong
2025-01-13  3:18     ` Alistair Popple
2025-01-14  3:35   ` Dan Williams
2025-02-07  5:31     ` Alistair Popple
2025-02-07  5:50       ` Dan Williams
2025-02-09 23:35         ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 22/26] device/dax: Properly refcount device dax pages when mapping Alistair Popple
2025-01-14  6:12   ` Dan Williams
2025-02-03 11:29     ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 23/26] mm: Remove pXX_devmap callers Alistair Popple
2025-01-14 18:50   ` Dan Williams
2025-01-15  7:27     ` Alistair Popple
2025-02-04 19:06       ` Dan Williams
2025-02-05  9:57         ` Alistair Popple
2025-01-10  6:00 ` [PATCH v6 24/26] mm: Remove devmap related functions and page table bits Alistair Popple
2025-01-11 10:08   ` Huacai Chen
2025-01-14 19:03   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 25/26] Revert "riscv: mm: Add support for ZONE_DEVICE" Alistair Popple
2025-01-14 19:11   ` Dan Williams
2025-01-10  6:00 ` [PATCH v6 26/26] Revert "LoongArch: Add ARCH_HAS_PTE_DEVMAP support" Alistair Popple
2025-01-10  7:05 ` [PATCH v6 00/26] fs/dax: Fix ZONE_DEVICE page reference counts Dan Williams
2025-01-11  1:30   ` Andrew Morton
2025-01-11  3:35     ` Dan Williams
2025-01-13  1:05       ` Alistair Popple

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6785a26d48c86_20fa294d8@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alison.schofield@intel.com \
    --cc=apopple@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=david@fromorbit.com \
    --cc=david@redhat.com \
    --cc=djwong@kernel.org \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=ira.weiny@intel.com \
    --cc=jack@suse.cz \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=kernel@xen0n.name \
    --cc=lina@asahilina.net \
    --cc=linmiaohe@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=logang@deltatee.com \
    --cc=loongarch@lists.linux.dev \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=peterx@redhat.com \
    --cc=tytso@mit.edu \
    --cc=vishal.l.verma@intel.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=zhang.lyra@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox