From: Alistair Popple <apopple@nvidia.com>
To: dan.j.williams@intel.com, linux-mm@kvack.org
Cc: 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,
Vivek Goyal <vgoyal@redhat.com>
Subject: [PATCH v3 01/25] fuse: Fix dax truncate/punch_hole fault path
Date: Fri, 22 Nov 2024 12:40:22 +1100 [thread overview]
Message-ID: <bdceb724f486dbaecb026aad8b224cc247a6b11e.1732239628.git-series.apopple@nvidia.com> (raw)
In-Reply-To: <cover.e1ebdd6cab9bde0d232c1810deacf0bae25e6707.1732239628.git-series.apopple@nvidia.com>
FS DAX requires file systems to call into the DAX layout prior to
unlinking inodes to ensure there is no ongoing DMA or other remote
access to the direct mapped page. The fuse file system implements
fuse_dax_break_layouts() to do this which includes a comment
indicating that passing dmap_end == 0 leads to unmapping of the whole
file.
However this is not true - passing dmap_end == 0 will not unmap
anything before dmap_start, and further more
dax_layout_busy_page_range() will not scan any of the range to see if
there maybe ongoing DMA access to the range. Fix this by checking for
dmap_end == 0 in fuse_dax_break_layouts() and pass the entire file
range to dax_layout_busy_page_range().
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Fixes: 6ae330cad6ef ("virtiofs: serialize truncate/punch_hole and dax fault path")
Cc: Vivek Goyal <vgoyal@redhat.com>
---
I am not at all familiar with the fuse file system driver so I have no
idea if the comment is relevant or not and whether the documented
behaviour for dmap_end == 0 is ever relied upon. However this seemed
like the safest fix unless someone more familiar with fuse can confirm
that dmap_end == 0 is never used.
---
fs/fuse/dax.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/fuse/dax.c b/fs/fuse/dax.c
index 12ef91d..501a097 100644
--- a/fs/fuse/dax.c
+++ b/fs/fuse/dax.c
@@ -693,6 +693,10 @@ int fuse_dax_break_layouts(struct inode *inode, u64 dmap_start,
ret = __fuse_dax_break_layouts(inode, &retry, dmap_start,
dmap_end);
} while (ret == 0 && retry);
+ if (!dmap_end) {
+ dmap_start = 0;
+ dmap_end = LLONG_MAX;
+ }
return ret;
}
--
git-series 0.9.1
next prev parent reply other threads:[~2024-11-22 1:41 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-22 1:40 [PATCH v3 00/25] fs/dax: Fix ZONE_DEVICE page reference counts Alistair Popple
2024-11-22 1:40 ` Alistair Popple [this message]
2024-11-22 1:40 ` [PATCH v3 02/25] fs/dax: Return unmapped busy pages from dax_layout_busy_page_range() Alistair Popple
2024-11-22 1:40 ` [PATCH v3 03/25] fs/dax: Don't skip locked entries when scanning entries Alistair Popple
2024-11-22 1:40 ` [PATCH v3 04/25] fs/dax: Refactor wait for dax idle page Alistair Popple
2024-11-22 1:40 ` [PATCH v3 05/25] fs/dax: Create a common implementation to break DAX layouts Alistair Popple
2024-11-22 2:57 ` John Hubbard
2024-11-22 3:37 ` Alistair Popple
2024-11-25 13:27 ` kernel test robot
2024-11-22 1:40 ` [PATCH v3 06/25] fs/dax: Always remove DAX page-cache entries when breaking layouts Alistair Popple
2024-11-22 1:40 ` [PATCH v3 07/25] fs/dax: Ensure all pages are idle prior to filesystem unmount Alistair Popple
2024-11-22 1:40 ` [PATCH v3 08/25] fs/dax: Remove PAGE_MAPPING_DAX_SHARED mapping flag Alistair Popple
2024-11-22 1:40 ` [PATCH v3 09/25] mm/gup.c: Remove redundant check for PCI P2PDMA page Alistair Popple
2024-11-22 1:40 ` [PATCH v3 10/25] pci/p2pdma: Don't initialise page refcount to one Alistair Popple
2024-11-22 18:20 ` Bjorn Helgaas
2024-11-24 22:39 ` Alistair Popple
2024-11-22 1:40 ` [PATCH v3 11/25] mm: Allow compound zone device pages Alistair Popple
2024-11-25 5:05 ` kernel test robot
2024-11-25 15:51 ` kernel test robot
2024-11-22 1:40 ` [PATCH v3 12/25] mm/memory: Enhance insert_page_into_pte_locked() to create writable mappings Alistair Popple
2024-11-22 1:40 ` [PATCH v3 13/25] mm/memory: Add vmf_insert_page_mkwrite() Alistair Popple
2024-11-22 1:40 ` [PATCH v3 14/25] huge_memory: Allow mappings of PUD sized pages Alistair Popple
2024-12-14 15:32 ` David Hildenbrand
2024-11-22 1:40 ` [PATCH v3 15/25] huge_memory: Allow mappings of PMD " Alistair Popple
2024-11-22 1:40 ` [PATCH v3 16/25] memremap: Add is_device_dax_page() and is_fsdax_page() helpers Alistair Popple
2024-11-22 1:40 ` [PATCH v3 17/25] gup: Don't allow FOLL_LONGTERM pinning of FS DAX pages Alistair Popple
2024-11-22 3:23 ` John Hubbard
2024-11-22 1:40 ` [PATCH v3 18/25] proc/task_mmu: Ignore ZONE_DEVICE pages Alistair Popple
2024-11-22 1:40 ` [PATCH v3 19/25] memcontrol-v1: " Alistair Popple
2024-11-22 1:40 ` [PATCH v3 20/25] mm/mlock: Skip ZONE_DEVICE PMDs during mlock Alistair Popple
2024-11-22 1:40 ` [PATCH v3 21/25] fs/dax: Properly refcount fs dax pages Alistair Popple
2024-11-22 1:40 ` [PATCH v3 22/25] device/dax: Properly refcount device dax pages when mapping Alistair Popple
2024-11-22 1:40 ` [PATCH v3 23/25] mm: Remove pXX_devmap callers Alistair Popple
2024-11-22 1:40 ` [PATCH v3 24/25] mm: Remove devmap related functions and page table bits Alistair Popple
2024-11-22 1:40 ` [PATCH v3 25/25] Revert "riscv: mm: Add support for ZONE_DEVICE" Alistair Popple
2024-11-25 13:13 ` Björn Töpel
2024-12-14 1:39 ` [PATCH v3 00/25] fs/dax: Fix ZONE_DEVICE page reference counts Dan Williams
2024-12-14 15:22 ` David Hildenbrand
2024-12-16 0:55 ` Alistair Popple
2024-12-16 6:26 ` Andrew Morton
2024-12-17 5:20 ` 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=bdceb724f486dbaecb026aad8b224cc247a6b11e.1732239628.git-series.apopple@nvidia.com \
--to=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=dan.j.williams@intel.com \
--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=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=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=nvdimm@lists.linux.dev \
--cc=peterx@redhat.com \
--cc=tytso@mit.edu \
--cc=vgoyal@redhat.com \
--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
all inboxes | Powered by JetHome®