From: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Tejun Heo <tj@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Manivannan Sadhasivam <mani@kernel.org>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Baoquan He <baoquan.he@linux.dev>,
Pratyush Yadav <pratyush@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
Mike Rapoport <rppt@kernel.org>,
Simona Vetter <simona.vetter@ffwll.ch>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@kernel.org>,
Dave Young <ruirui.yang@linux.dev>,
linux-mm@kvack.org, linux-pci@vger.kernel.org,
linux-sound@vger.kernel.org, kexec@lists.infradead.org,
driver-core@lists.linux.dev
Subject: [PATCH v2 1/3] mm: Add unmap_mapping_file() helper
Date: Sat, 25 Jul 2026 21:05:47 +0000 [thread overview]
Message-ID: <20260725210549.3716546-2-kwilczynski@kernel.org> (raw)
In-Reply-To: <20260725210549.3716546-1-kwilczynski@kernel.org>
Currently, unmap_mapping_pages() and unmap_mapping_range() unmap a
page offset window of an address_space, and code that removes a file,
such as kernfs_drain_open_files(), relies on them to unmap the pages
of a file that is going away.
Files with f_mapping swapped to a shared address space at open time,
such as PCI resource files using iomem_get_mapping(), have their VMAs
attached to the shared mapping instead of the file's own inode mapping,
so unmapping the inode's address space cannot reach them, and they stay
live after the file is removed. These VMAs can only be selected by the
struct file they were created through, which is recorded in
vma->vm_file.
Thus, add unmap_mapping_file(), which walks the VMA interval tree of the
file's f_mapping under i_mmap_lock_read() and unmaps the pages of the
VMAs selected by should_zap_file_vma(), using the same per-VMA zap as
unmap_mapping_pages(). When f_mapping is the file's own inode mapping,
every VMA is zapped, as unmap_mapping_range() does today. When f_mapping
was swapped, only the VMAs with vm_file set to that file are zapped, so
callers do not need to tell the two apart.
HugeTLB VMAs are skipped with a WARN_ON_ONCE(), as zapping those takes
i_mmap_rwsem for write in hugetlb_zap_begin() and would deadlock against
the read lock held over the walk.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
---
include/linux/mm.h | 2 ++
mm/memory.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 485df9c2dbdd..e882a03eaddd 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -3183,6 +3183,7 @@ extern int fixup_user_fault(struct mm_struct *mm,
bool *unlocked);
void unmap_mapping_pages(struct address_space *mapping,
pgoff_t start, pgoff_t nr, bool even_cows);
+void unmap_mapping_file(struct file *file);
void unmap_mapping_range(struct address_space *mapping,
loff_t const holebegin, loff_t const holelen, int even_cows);
#else
@@ -3203,6 +3204,7 @@ static inline int fixup_user_fault(struct mm_struct *mm, unsigned long address,
}
static inline void unmap_mapping_pages(struct address_space *mapping,
pgoff_t start, pgoff_t nr, bool even_cows) { }
+static inline void unmap_mapping_file(struct file *file) { }
static inline void unmap_mapping_range(struct address_space *mapping,
loff_t const holebegin, loff_t const holelen, int even_cows) { }
#endif
diff --git a/mm/memory.c b/mm/memory.c
index ff338c2abe92..4a09d7b6aa6b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4423,6 +4423,54 @@ void unmap_mapping_pages(struct address_space *mapping, pgoff_t start,
}
EXPORT_SYMBOL_GPL(unmap_mapping_pages);
+static inline bool should_zap_file_vma(struct file *file,
+ struct vm_area_struct *vma)
+{
+ /* On the file's own inode mapping, zap every VMA */
+ if (file->f_mapping == file_inode(file)->i_mapping)
+ return true;
+
+ /* A swapped mapping also holds VMAs of unrelated files, zap only ours */
+ return vma->vm_file == file;
+}
+
+/**
+ * unmap_mapping_file() - Unmap folios from all mmaps of a file.
+ * @file: The file to unmap.
+ *
+ * Unmap the folios of @file from every process that has them mapped.
+ *
+ * If f_mapping is the file's own inode mapping, they are unmapped
+ * from every VMA on that mapping, as unmap_mapping_range() would do.
+ *
+ * However, if f_mapping was swapped to a different address space at
+ * open time, only the VMAs with vm_file set to @file are considered,
+ * since that address space also holds mappings of unrelated files.
+ *
+ * Must not be used on HugeTLB files. HugeTLB VMAs are skipped with
+ * a warning.
+ */
+void unmap_mapping_file(struct file *file)
+{
+ struct address_space *mapping = file->f_mapping;
+ struct vm_area_struct *vma;
+
+ i_mmap_lock_read(mapping);
+ if (unlikely(mapping_mapped(mapping))) {
+ vma_interval_tree_foreach(vma, &mapping->i_mmap, 0, ULONG_MAX) {
+ cond_resched();
+
+ if (!should_zap_file_vma(file, vma))
+ continue;
+ /* Zapping HugeTLB VMAs needs i_mmap_rwsem held for write */
+ if (WARN_ON_ONCE(is_vm_hugetlb_page(vma)))
+ continue;
+ zap_vma(vma);
+ }
+ }
+ i_mmap_unlock_read(mapping);
+}
+
/**
* unmap_mapping_range - unmap the portion of all mmaps in the specified
* address_space corresponding to the specified byte range in the underlying
--
2.55.0
next prev parent reply other threads:[~2026-07-25 21:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 21:05 [PATCH v2 0/3] mm,kernfs,proc: Unmap mmaps of removed files via file->f_mapping Krzysztof Wilczyński
2026-07-25 21:05 ` Krzysztof Wilczyński [this message]
2026-07-25 21:35 ` [PATCH v2 1/3] mm: Add unmap_mapping_file() helper sashiko-bot
2026-07-25 21:05 ` [PATCH v2 2/3] kernfs: Unmap mmaps of removed files via file->f_mapping Krzysztof Wilczyński
2026-07-25 21:22 ` sashiko-bot
2026-07-25 21:05 ` [PATCH v2 3/3] proc: " Krzysztof Wilczyński
2026-07-25 21:19 ` sashiko-bot
2026-07-25 21:37 ` [PATCH v2 0/3] mm,kernfs,proc: " Andrew Morton
2026-07-26 1:22 ` Krzysztof Wilczyński
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=20260725210549.3716546-2-kwilczynski@kernel.org \
--to=kwilczynski@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baoquan.he@linux.dev \
--cc=bhelgaas@google.com \
--cc=david@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mhocko@suse.com \
--cc=pasha.tatashin@soleen.com \
--cc=perex@perex.cz \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=simona.vetter@ffwll.ch \
--cc=surenb@google.com \
--cc=tiwai@suse.com \
--cc=tj@kernel.org \
--cc=vbabka@kernel.org \
/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