From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.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>,
Dan Williams <djbw@kernel.org>, 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>,
linux-pci@vger.kernel.org, linux-mm@kvack.org,
driver-core@lists.linux.dev,
Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH 1/2] mm: Add unmap_mapping_file() helper
Date: Tue, 21 Jul 2026 21:19:59 +0200 [thread overview]
Message-ID: <5a43053d-8d08-4fda-82e3-bda10ca79c92@kernel.org> (raw)
In-Reply-To: <20260721185252.1670958-2-kwilczynski@kernel.org>
On 7/21/26 20:52, Krzysztof Wilczyński wrote:
> Currently, unmap_mapping_pages() and unmap_mapping_range() unmap
> a page offset window of an address_space, and teardown paths such
> as kernfs_drain_open_files() rely on them to remove the mappings
> 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 a teardown that unmaps the inode's address space cannot
> reach them, and they stay live after the file is removed. As such,
> the only correct discriminator for these VMAs is the originating
> struct file recorded in vma->vm_file.
>
> Add unmap_mapping_file(), which walks the VMA interval tree of the
> file's f_mapping under i_mmap_lock_read() and zaps every VMA with
> vm_file set to the given file, using the same per-VMA zap teardown
> as unmap_mapping_pages().
>
> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
> ---
> include/linux/mm.h | 2 ++
> mm/memory.c | 26 ++++++++++++++++++++++++++
> 2 files changed, 28 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..f9cfb88ac4f7 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4423,6 +4423,32 @@ void unmap_mapping_pages(struct address_space *mapping, pgoff_t start,
> }
> EXPORT_SYMBOL_GPL(unmap_mapping_pages);
>
> +/**
> + * unmap_mapping_file() - Unmap all mmaps of an open file.
> + * @file: The file to unmap.
We are unmapping pages/folios, not really mmaps.
"Unmap folio from all mmaps of a file." ?
> + *
> + * Unmap every VMA with vm_file set to @file, regardless of the address
Again, we are not unmapping VMAs, we are unmapping pages/folios within all VMAs
that map the file.
> + * space it is attached to. This also covers files with f_mapping
> + * swapped to a different address space at open time, since such VMAs
> + * cannot be found through the file's own inode mapping.
God this is confusing :)
Sorry for the stupid question, but why can't we call
unmap_mapping_range(file->f_mapping, 0, 0, 1);
What is a bit annoying is that you now do in the caller:
if (of->file->f_mapping != inode->i_mapping)
unmap_mapping_file(of->file);
else
unmap_mapping_range(inode->i_mapping, 0, 0, 1);
Shouldn't we just have one function that takes care of that internally ... so
it's harder to get wrong?
--
Cheers,
David
next prev parent reply other threads:[~2026-07-21 19:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 18:52 [PATCH 0/2] mm,kernfs: Fix stale userspace mappings after sysfs file removal Krzysztof Wilczyński
2026-07-21 18:52 ` [PATCH 1/2] mm: Add unmap_mapping_file() helper Krzysztof Wilczyński
2026-07-21 19:19 ` David Hildenbrand (Arm) [this message]
2026-07-22 4:15 ` Krzysztof Wilczyński
2026-07-21 18:52 ` [PATCH 2/2] kernfs: Unmap mmaps of removed files via file->f_mapping 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=5a43053d-8d08-4fda-82e3-bda10ca79c92@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=brauner@kernel.org \
--cc=djbw@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=simona.vetter@ffwll.ch \
--cc=surenb@google.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