diff mbox series

[2/4] mm: add a io_mapping_map_user helper

Message ID 20210326055505.1424432-3-hch@lst.de (mailing list archive)
State New, archived
Headers show
Series [1/4] mm: add remap_pfn_range_notrack | expand

Commit Message

Christoph Hellwig March 26, 2021, 5:55 a.m. UTC
Add a helper that calls remap_pfn_range for an struct io_mapping, relying
on the pgprot pre-validation done when creating the mapping instead of
doing it at runtime.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/io-mapping.h |  3 +++
 mm/Kconfig                 |  3 +++
 mm/Makefile                |  1 +
 mm/io-mapping.c            | 29 +++++++++++++++++++++++++++++
 4 files changed, 36 insertions(+)
 create mode 100644 mm/io-mapping.c

Comments

Lucas De Marchi Oct. 20, 2021, 3:40 p.m. UTC | #1
On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
>Add a helper that calls remap_pfn_range for an struct io_mapping, relying
>on the pgprot pre-validation done when creating the mapping instead of
>doing it at runtime.
>
>Signed-off-by: Christoph Hellwig <hch@lst.de>
>---
> include/linux/io-mapping.h |  3 +++
> mm/Kconfig                 |  3 +++
> mm/Makefile                |  1 +
> mm/io-mapping.c            | 29 +++++++++++++++++++++++++++++
> 4 files changed, 36 insertions(+)
> create mode 100644 mm/io-mapping.c
>
>diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
>index c093e81310a9b3..e9743cfd858527 100644
>--- a/include/linux/io-mapping.h
>+++ b/include/linux/io-mapping.h
>@@ -220,3 +220,6 @@ io_mapping_free(struct io_mapping *iomap)
> }
>
> #endif /* _LINUX_IO_MAPPING_H */
>+
>+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
>+		unsigned long addr, unsigned long pfn, unsigned long size);

I'm not sure what exactly brought me to check this, but while debugging
I noticed this outside the header guard. But then after some more checks I
saw nothing actually selects CONFIG_IO_MAPPING because commit using
it was reverted in commit 0e4fe0c9f2f9 ("Revert "i915: use io_mapping_map_user"")

Is this something we want to re-attempt moving to mm/ ?

thanks
Lucas De Marchi

>diff --git a/mm/Kconfig b/mm/Kconfig
>index 24c045b24b9506..6b0f2cfbfac0f3 100644
>--- a/mm/Kconfig
>+++ b/mm/Kconfig
>@@ -872,4 +872,7 @@ config MAPPING_DIRTY_HELPERS
> config KMAP_LOCAL
> 	bool
>
>+# struct io_mapping based helper.  Selected by drivers that need them
>+config IO_MAPPING
>+	bool
> endmenu
>diff --git a/mm/Makefile b/mm/Makefile
>index 72227b24a61688..c0135e385984bb 100644
>--- a/mm/Makefile
>+++ b/mm/Makefile
>@@ -120,3 +120,4 @@ obj-$(CONFIG_MEMFD_CREATE) += memfd.o
> obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o
> obj-$(CONFIG_PTDUMP_CORE) += ptdump.o
> obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
>+obj-$(CONFIG_IO_MAPPING) += io-mapping.o
>diff --git a/mm/io-mapping.c b/mm/io-mapping.c
>new file mode 100644
>index 00000000000000..01b3627999304e
>--- /dev/null
>+++ b/mm/io-mapping.c
>@@ -0,0 +1,29 @@
>+// SPDX-License-Identifier: GPL-2.0-only
>+
>+#include <linux/mm.h>
>+#include <linux/io-mapping.h>
>+
>+/**
>+ * io_mapping_map_user - remap an I/O mapping to userspace
>+ * @iomap: the source io_mapping
>+ * @vma: user vma to map to
>+ * @addr: target user address to start at
>+ * @pfn: physical address of kernel memory
>+ * @size: size of map area
>+ *
>+ *  Note: this is only safe if the mm semaphore is held when called.
>+ */
>+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
>+		unsigned long addr, unsigned long pfn, unsigned long size)
>+{
>+	vm_flags_t expected_flags = VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
>+
>+	if (WARN_ON_ONCE((vma->vm_flags & expected_flags) != expected_flags))
>+		return -EINVAL;
>+
>+	/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
>+	return remap_pfn_range_notrack(vma, addr, pfn, size,
>+		__pgprot((pgprot_val(iomap->prot) & _PAGE_CACHE_MASK) |
>+			 (pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK)));
>+}
>+EXPORT_SYMBOL_GPL(io_mapping_map_user);
>-- 
>2.30.1
>
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
Peter Zijlstra Oct. 20, 2021, 7:37 p.m. UTC | #2
On Wed, Oct 20, 2021 at 08:40:05AM -0700, Lucas De Marchi wrote:
> On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
> > Add a helper that calls remap_pfn_range for an struct io_mapping, relying
> > on the pgprot pre-validation done when creating the mapping instead of
> > doing it at runtime.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > include/linux/io-mapping.h |  3 +++
> > mm/Kconfig                 |  3 +++
> > mm/Makefile                |  1 +
> > mm/io-mapping.c            | 29 +++++++++++++++++++++++++++++
> > 4 files changed, 36 insertions(+)
> > create mode 100644 mm/io-mapping.c
> > 
> > diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
> > index c093e81310a9b3..e9743cfd858527 100644
> > --- a/include/linux/io-mapping.h
> > +++ b/include/linux/io-mapping.h
> > @@ -220,3 +220,6 @@ io_mapping_free(struct io_mapping *iomap)
> > }
> > 
> > #endif /* _LINUX_IO_MAPPING_H */
> > +
> > +int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
> > +		unsigned long addr, unsigned long pfn, unsigned long size);
> 
> I'm not sure what exactly brought me to check this, but while debugging
> I noticed this outside the header guard. But then after some more checks I
> saw nothing actually selects CONFIG_IO_MAPPING because commit using
> it was reverted in commit 0e4fe0c9f2f9 ("Revert "i915: use io_mapping_map_user"")
> 
> Is this something we want to re-attempt moving to mm/ ?

Yes, it would be very good to unexport apply_to_page_range(), it's a
terrible interface to expose.
Christoph Hellwig Oct. 21, 2021, 6:18 a.m. UTC | #3
On Wed, Oct 20, 2021 at 09:37:51PM +0200, Peter Zijlstra wrote:
> > I'm not sure what exactly brought me to check this, but while debugging
> > I noticed this outside the header guard. But then after some more checks I
> > saw nothing actually selects CONFIG_IO_MAPPING because commit using
> > it was reverted in commit 0e4fe0c9f2f9 ("Revert "i915: use io_mapping_map_user"")
> > 
> > Is this something we want to re-attempt moving to mm/ ?
> 
> Yes, it would be very good to unexport apply_to_page_range(), it's a
> terrible interface to expose.

Yes.  We need to get back to this rather sooner than later.  I'm a little
swamped unfortunately.
diff mbox series

Patch

diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index c093e81310a9b3..e9743cfd858527 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -220,3 +220,6 @@  io_mapping_free(struct io_mapping *iomap)
 }
 
 #endif /* _LINUX_IO_MAPPING_H */
+
+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
+		unsigned long addr, unsigned long pfn, unsigned long size);
diff --git a/mm/Kconfig b/mm/Kconfig
index 24c045b24b9506..6b0f2cfbfac0f3 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -872,4 +872,7 @@  config MAPPING_DIRTY_HELPERS
 config KMAP_LOCAL
 	bool
 
+# struct io_mapping based helper.  Selected by drivers that need them
+config IO_MAPPING
+	bool
 endmenu
diff --git a/mm/Makefile b/mm/Makefile
index 72227b24a61688..c0135e385984bb 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -120,3 +120,4 @@  obj-$(CONFIG_MEMFD_CREATE) += memfd.o
 obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o
 obj-$(CONFIG_PTDUMP_CORE) += ptdump.o
 obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
+obj-$(CONFIG_IO_MAPPING) += io-mapping.o
diff --git a/mm/io-mapping.c b/mm/io-mapping.c
new file mode 100644
index 00000000000000..01b3627999304e
--- /dev/null
+++ b/mm/io-mapping.c
@@ -0,0 +1,29 @@ 
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/mm.h>
+#include <linux/io-mapping.h>
+
+/**
+ * io_mapping_map_user - remap an I/O mapping to userspace
+ * @iomap: the source io_mapping
+ * @vma: user vma to map to
+ * @addr: target user address to start at
+ * @pfn: physical address of kernel memory
+ * @size: size of map area
+ *
+ *  Note: this is only safe if the mm semaphore is held when called.
+ */
+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
+		unsigned long addr, unsigned long pfn, unsigned long size)
+{
+	vm_flags_t expected_flags = VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+
+	if (WARN_ON_ONCE((vma->vm_flags & expected_flags) != expected_flags))
+		return -EINVAL;
+
+	/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
+	return remap_pfn_range_notrack(vma, addr, pfn, size,
+		__pgprot((pgprot_val(iomap->prot) & _PAGE_CACHE_MASK) |
+			 (pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK)));
+}
+EXPORT_SYMBOL_GPL(io_mapping_map_user);