[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250328211349.845857-1-vishal.moola@gmail.com>
Date: Fri, 28 Mar 2025 14:13:48 -0700
From: "Vishal Moola (Oracle)" <vishal.moola@...il.com>
To: linux-mm@...ck.org
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Brendan Jackman <jackmanb@...gle.com>,
Huan Yang <link@...o.com>,
linux-kernel@...r.kernel.org,
"Vishal Moola (Oracle)" <vishal.moola@...il.com>
Subject: [RFC PATCH v2 0/1] Introduce vmap_file()
Currently, users have to call vmap() or vmap_pfn() to map pages to
kernel virtual space. vmap_pfn() is for special pages (i.e. pfns
without struct page). vmap() handles normal pages.
With large folios, we may want to map ranges that only span
part of a folio (i.e. mapping half of a 2Mb folio).
vmap_file() will allow us to do so.
Create a function, vmap_file(), to map a specified range of a given
file to kernel virtual space. vmap_file() is an in-kernel equivalent
to mmap(), and can be useful for filesystems.
---
v2:
- Reword cover letter to provide a clearer overview of the current
vmalloc APIs, and usefulness of vmap_file()
- EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL()
- Provide support to partially map file folios
- Demote this to RFC while we look for users
--
I don't have a user for this function right now, but it will be
useful as users start converting to using large folios. I'm just
putting it out here for anyone that may find a use for it.
This seems like the sensible way to implement it, but I'm open
to tweaking the functions semantics.
I've Cc-ed a couple people that mentioned they might be interested
in using it.
Vishal Moola (Oracle) (1):
mm/vmalloc: Introduce vmap_file()
include/linux/vmalloc.h | 2 +
mm/vmalloc.c | 113 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 115 insertions(+)
--
2.48.1
Powered by blists - more mailing lists