All of lore.kernel.org
 help / color / mirror / Atom feed
* add remap_pfn_range_notrack instead of reinventing it in i915 v2
@ 2021-03-26  5:55 ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Chris Wilson, Daniel Vetter, Peter Zijlstra, intel-gfx,
	dri-devel, linux-mm

Hi all,

i915 has some reason to want to avoid the track_pfn_remap overhead in
remap_pfn_range.  Add a function to the core VM to do just that rather
than reinventing the functionality poorly in the driver.

Note that the remap_io_sg path does get exercises when using Xorg on my
Thinkpad X1, so this should be considered lightly tested, I've not
managed to hit the remap_io_mapping path at all.

Changes since v1:
 - create a io_mapping_map_user wrapper instead of exporting
   remap_pfn_range_notrack
 - switch to plain remap_pfn_range for remap_sg as it does not use
   a pre-verified pgprot from an iomap

Diffstat:
 drivers/gpu/drm/i915/Kconfig             |    1 
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |    9 +-
 drivers/gpu/drm/i915/i915_drv.h          |    3 
 drivers/gpu/drm/i915/i915_mm.c           |  117 ++++++-------------------------
 include/linux/io-mapping.h               |    3 
 include/linux/mm.h                       |    2 
 mm/Kconfig                               |    3 
 mm/Makefile                              |    1 
 mm/io-mapping.c                          |   29 +++++++
 mm/memory.c                              |   51 ++++++++-----
 10 files changed, 97 insertions(+), 122 deletions(-)


^ permalink raw reply	[flat|nested] 63+ messages in thread

* [Intel-gfx] add remap_pfn_range_notrack instead of reinventing it in i915 v2
@ 2021-03-26  5:55 ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm

Hi all,

i915 has some reason to want to avoid the track_pfn_remap overhead in
remap_pfn_range.  Add a function to the core VM to do just that rather
than reinventing the functionality poorly in the driver.

Note that the remap_io_sg path does get exercises when using Xorg on my
Thinkpad X1, so this should be considered lightly tested, I've not
managed to hit the remap_io_mapping path at all.

Changes since v1:
 - create a io_mapping_map_user wrapper instead of exporting
   remap_pfn_range_notrack
 - switch to plain remap_pfn_range for remap_sg as it does not use
   a pre-verified pgprot from an iomap

Diffstat:
 drivers/gpu/drm/i915/Kconfig             |    1 
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |    9 +-
 drivers/gpu/drm/i915/i915_drv.h          |    3 
 drivers/gpu/drm/i915/i915_mm.c           |  117 ++++++-------------------------
 include/linux/io-mapping.h               |    3 
 include/linux/mm.h                       |    2 
 mm/Kconfig                               |    3 
 mm/Makefile                              |    1 
 mm/io-mapping.c                          |   29 +++++++
 mm/memory.c                              |   51 ++++++++-----
 10 files changed, 97 insertions(+), 122 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [PATCH 1/4] mm: add remap_pfn_range_notrack
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
@ 2021-03-26  5:55   ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Chris Wilson, Daniel Vetter, Peter Zijlstra, intel-gfx,
	dri-devel, linux-mm

Add a version of remap_pfn_range that does not call track_pfn_range.
This will be used to fix horrible abuses of VM internals in the i915
driver.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/mm.h |  2 ++
 mm/memory.c        | 51 ++++++++++++++++++++++++++++------------------
 2 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 64a71bf2053674..70a6160d729ded 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2709,6 +2709,8 @@ unsigned long change_prot_numa(struct vm_area_struct *vma,
 struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
 int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
 			unsigned long pfn, unsigned long size, pgprot_t);
+int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr,
+		unsigned long pfn, unsigned long size, pgprot_t prot);
 int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
 int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
 			struct page **pages, unsigned long *num);
diff --git a/mm/memory.c b/mm/memory.c
index 5efa07fb6cdc18..997cda24c4a0be 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2260,26 +2260,17 @@ static inline int remap_p4d_range(struct mm_struct *mm, pgd_t *pgd,
 	return 0;
 }
 
-/**
- * remap_pfn_range - remap kernel memory to userspace
- * @vma: user vma to map to
- * @addr: target page aligned user address to start at
- * @pfn: page frame number of kernel physical memory address
- * @size: size of mapping area
- * @prot: page protection flags for this mapping
- *
- * Note: this is only safe if the mm semaphore is held when called.
- *
- * Return: %0 on success, negative error code otherwise.
+/*
+ * Variant of remap_pfn_range that does not call track_pfn_remap.  The caller
+ * must have pre-validated the caching bits of the pgprot_t.
  */
-int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
-		    unsigned long pfn, unsigned long size, pgprot_t prot)
+int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr,
+		unsigned long pfn, unsigned long size, pgprot_t prot)
 {
 	pgd_t *pgd;
 	unsigned long next;
 	unsigned long end = addr + PAGE_ALIGN(size);
 	struct mm_struct *mm = vma->vm_mm;
-	unsigned long remap_pfn = pfn;
 	int err;
 
 	if (WARN_ON_ONCE(!PAGE_ALIGNED(addr)))
@@ -2309,10 +2300,6 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
 		vma->vm_pgoff = pfn;
 	}
 
-	err = track_pfn_remap(vma, &prot, remap_pfn, addr, PAGE_ALIGN(size));
-	if (err)
-		return -EINVAL;
-
 	vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
 
 	BUG_ON(addr >= end);
@@ -2324,12 +2311,36 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
 		err = remap_p4d_range(mm, pgd, addr, next,
 				pfn + (addr >> PAGE_SHIFT), prot);
 		if (err)
-			break;
+			return err;
 	} while (pgd++, addr = next, addr != end);
 
+	return 0;
+}
+
+/**
+ * remap_pfn_range - remap kernel memory to userspace
+ * @vma: user vma to map to
+ * @addr: target page aligned user address to start at
+ * @pfn: page frame number of kernel physical memory address
+ * @size: size of mapping area
+ * @prot: page protection flags for this mapping
+ *
+ * Note: this is only safe if the mm semaphore is held when called.
+ *
+ * Return: %0 on success, negative error code otherwise.
+ */
+int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
+		    unsigned long pfn, unsigned long size, pgprot_t prot)
+{
+	int err;
+
+	err = track_pfn_remap(vma, &prot, pfn, addr, PAGE_ALIGN(size));
 	if (err)
-		untrack_pfn(vma, remap_pfn, PAGE_ALIGN(size));
+		return -EINVAL;
 
+	err = remap_pfn_range_notrack(vma, addr, pfn, size, prot);
+	if (err)
+		untrack_pfn(vma, pfn, PAGE_ALIGN(size));
 	return err;
 }
 EXPORT_SYMBOL(remap_pfn_range);
-- 
2.30.1



^ permalink raw reply related	[flat|nested] 63+ messages in thread

* [Intel-gfx] [PATCH 1/4] mm: add remap_pfn_range_notrack
@ 2021-03-26  5:55   ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm

Add a version of remap_pfn_range that does not call track_pfn_range.
This will be used to fix horrible abuses of VM internals in the i915
driver.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/mm.h |  2 ++
 mm/memory.c        | 51 ++++++++++++++++++++++++++++------------------
 2 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 64a71bf2053674..70a6160d729ded 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2709,6 +2709,8 @@ unsigned long change_prot_numa(struct vm_area_struct *vma,
 struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long addr);
 int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
 			unsigned long pfn, unsigned long size, pgprot_t);
+int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr,
+		unsigned long pfn, unsigned long size, pgprot_t prot);
 int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
 int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
 			struct page **pages, unsigned long *num);
diff --git a/mm/memory.c b/mm/memory.c
index 5efa07fb6cdc18..997cda24c4a0be 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2260,26 +2260,17 @@ static inline int remap_p4d_range(struct mm_struct *mm, pgd_t *pgd,
 	return 0;
 }
 
-/**
- * remap_pfn_range - remap kernel memory to userspace
- * @vma: user vma to map to
- * @addr: target page aligned user address to start at
- * @pfn: page frame number of kernel physical memory address
- * @size: size of mapping area
- * @prot: page protection flags for this mapping
- *
- * Note: this is only safe if the mm semaphore is held when called.
- *
- * Return: %0 on success, negative error code otherwise.
+/*
+ * Variant of remap_pfn_range that does not call track_pfn_remap.  The caller
+ * must have pre-validated the caching bits of the pgprot_t.
  */
-int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
-		    unsigned long pfn, unsigned long size, pgprot_t prot)
+int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr,
+		unsigned long pfn, unsigned long size, pgprot_t prot)
 {
 	pgd_t *pgd;
 	unsigned long next;
 	unsigned long end = addr + PAGE_ALIGN(size);
 	struct mm_struct *mm = vma->vm_mm;
-	unsigned long remap_pfn = pfn;
 	int err;
 
 	if (WARN_ON_ONCE(!PAGE_ALIGNED(addr)))
@@ -2309,10 +2300,6 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
 		vma->vm_pgoff = pfn;
 	}
 
-	err = track_pfn_remap(vma, &prot, remap_pfn, addr, PAGE_ALIGN(size));
-	if (err)
-		return -EINVAL;
-
 	vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
 
 	BUG_ON(addr >= end);
@@ -2324,12 +2311,36 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
 		err = remap_p4d_range(mm, pgd, addr, next,
 				pfn + (addr >> PAGE_SHIFT), prot);
 		if (err)
-			break;
+			return err;
 	} while (pgd++, addr = next, addr != end);
 
+	return 0;
+}
+
+/**
+ * remap_pfn_range - remap kernel memory to userspace
+ * @vma: user vma to map to
+ * @addr: target page aligned user address to start at
+ * @pfn: page frame number of kernel physical memory address
+ * @size: size of mapping area
+ * @prot: page protection flags for this mapping
+ *
+ * Note: this is only safe if the mm semaphore is held when called.
+ *
+ * Return: %0 on success, negative error code otherwise.
+ */
+int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
+		    unsigned long pfn, unsigned long size, pgprot_t prot)
+{
+	int err;
+
+	err = track_pfn_remap(vma, &prot, pfn, addr, PAGE_ALIGN(size));
 	if (err)
-		untrack_pfn(vma, remap_pfn, PAGE_ALIGN(size));
+		return -EINVAL;
 
+	err = remap_pfn_range_notrack(vma, addr, pfn, size, prot);
+	if (err)
+		untrack_pfn(vma, pfn, PAGE_ALIGN(size));
 	return err;
 }
 EXPORT_SYMBOL(remap_pfn_range);
-- 
2.30.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 63+ messages in thread

* [PATCH 2/4] mm: add a io_mapping_map_user helper
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
@ 2021-03-26  5:55   ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Chris Wilson, Daniel Vetter, Peter Zijlstra, intel-gfx,
	dri-devel, linux-mm

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);
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



^ permalink raw reply related	[flat|nested] 63+ messages in thread

* [Intel-gfx] [PATCH 2/4] mm: add a io_mapping_map_user helper
@ 2021-03-26  5:55   ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm

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);
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

^ permalink raw reply related	[flat|nested] 63+ messages in thread

* [PATCH 3/4] i915: use io_mapping_map_user
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
@ 2021-03-26  5:55   ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Chris Wilson, Daniel Vetter, Peter Zijlstra, intel-gfx,
	dri-devel, linux-mm

Replace the home-grown remap_io_mapping that abuses apply_to_page_range
with the proper io_mapping_map_user interface.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/Kconfig             |  1 +
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  9 +++--
 drivers/gpu/drm/i915/i915_drv.h          |  3 --
 drivers/gpu/drm/i915/i915_mm.c           | 44 ------------------------
 4 files changed, 5 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca778..93f4d059fc89f6 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -20,6 +20,7 @@ config DRM_I915
 	select INPUT if ACPI
 	select ACPI_VIDEO if ACPI
 	select ACPI_BUTTON if ACPI
+	select IO_MAPPING
 	select SYNC_FILE
 	select IOSF_MBI
 	select CRC32
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index ec28a6cde49bdd..3ef734dd0a7c42 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -363,11 +363,10 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
 		goto err_unpin;
 
 	/* Finally, remap it using the new GTT offset */
-	ret = remap_io_mapping(area,
-			       area->vm_start + (vma->ggtt_view.partial.offset << PAGE_SHIFT),
-			       (ggtt->gmadr.start + vma->node.start) >> PAGE_SHIFT,
-			       min_t(u64, vma->size, area->vm_end - area->vm_start),
-			       &ggtt->iomap);
+	ret = io_mapping_map_user(&ggtt->iomap, area, area->vm_start +
+			(vma->ggtt_view.partial.offset << PAGE_SHIFT),
+			(ggtt->gmadr.start + vma->node.start) >> PAGE_SHIFT,
+			min_t(u64, vma->size, area->vm_end - area->vm_start));
 	if (ret)
 		goto err_fence;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cb62ddba203522..d6aaf0baa5c2fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1973,9 +1973,6 @@ int i915_reg_read_ioctl(struct drm_device *dev, void *data,
 			struct drm_file *file);
 
 /* i915_mm.c */
-int remap_io_mapping(struct vm_area_struct *vma,
-		     unsigned long addr, unsigned long pfn, unsigned long size,
-		     struct io_mapping *iomap);
 int remap_io_sg(struct vm_area_struct *vma,
 		unsigned long addr, unsigned long size,
 		struct scatterlist *sgl, resource_size_t iobase);
diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index 666808cb3a3260..9a777b0ff59b05 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -37,17 +37,6 @@ struct remap_pfn {
 	resource_size_t iobase;
 };
 
-static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
-{
-	struct remap_pfn *r = data;
-
-	/* Special PTE are not associated with any struct page */
-	set_pte_at(r->mm, addr, pte, pte_mkspecial(pfn_pte(r->pfn, r->prot)));
-	r->pfn++;
-
-	return 0;
-}
-
 #define use_dma(io) ((io) != -1)
 
 static inline unsigned long sgt_pfn(const struct remap_pfn *r)
@@ -77,40 +66,7 @@ static int remap_sg(pte_t *pte, unsigned long addr, void *data)
 	return 0;
 }
 
-/**
- * remap_io_mapping - remap an IO mapping to userspace
- * @vma: user vma to map to
- * @addr: target user address to start at
- * @pfn: physical address of kernel memory
- * @size: size of map area
- * @iomap: the source io_mapping
- *
- *  Note: this is only safe if the mm semaphore is held when called.
- */
-int remap_io_mapping(struct vm_area_struct *vma,
-		     unsigned long addr, unsigned long pfn, unsigned long size,
-		     struct io_mapping *iomap)
-{
-	struct remap_pfn r;
-	int err;
-
 #define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
-	GEM_BUG_ON((vma->vm_flags & EXPECTED_FLAGS) != EXPECTED_FLAGS);
-
-	/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
-	r.mm = vma->vm_mm;
-	r.pfn = pfn;
-	r.prot = __pgprot((pgprot_val(iomap->prot) & _PAGE_CACHE_MASK) |
-			  (pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK));
-
-	err = apply_to_page_range(r.mm, addr, size, remap_pfn, &r);
-	if (unlikely(err)) {
-		zap_vma_ptes(vma, addr, (r.pfn - pfn) << PAGE_SHIFT);
-		return err;
-	}
-
-	return 0;
-}
 
 /**
  * remap_io_sg - remap an IO mapping to userspace
-- 
2.30.1



^ permalink raw reply related	[flat|nested] 63+ messages in thread

* [Intel-gfx] [PATCH 3/4] i915: use io_mapping_map_user
@ 2021-03-26  5:55   ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm

Replace the home-grown remap_io_mapping that abuses apply_to_page_range
with the proper io_mapping_map_user interface.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/Kconfig             |  1 +
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  9 +++--
 drivers/gpu/drm/i915/i915_drv.h          |  3 --
 drivers/gpu/drm/i915/i915_mm.c           | 44 ------------------------
 4 files changed, 5 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 1e1cb245fca778..93f4d059fc89f6 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -20,6 +20,7 @@ config DRM_I915
 	select INPUT if ACPI
 	select ACPI_VIDEO if ACPI
 	select ACPI_BUTTON if ACPI
+	select IO_MAPPING
 	select SYNC_FILE
 	select IOSF_MBI
 	select CRC32
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index ec28a6cde49bdd..3ef734dd0a7c42 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -363,11 +363,10 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
 		goto err_unpin;
 
 	/* Finally, remap it using the new GTT offset */
-	ret = remap_io_mapping(area,
-			       area->vm_start + (vma->ggtt_view.partial.offset << PAGE_SHIFT),
-			       (ggtt->gmadr.start + vma->node.start) >> PAGE_SHIFT,
-			       min_t(u64, vma->size, area->vm_end - area->vm_start),
-			       &ggtt->iomap);
+	ret = io_mapping_map_user(&ggtt->iomap, area, area->vm_start +
+			(vma->ggtt_view.partial.offset << PAGE_SHIFT),
+			(ggtt->gmadr.start + vma->node.start) >> PAGE_SHIFT,
+			min_t(u64, vma->size, area->vm_end - area->vm_start));
 	if (ret)
 		goto err_fence;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cb62ddba203522..d6aaf0baa5c2fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1973,9 +1973,6 @@ int i915_reg_read_ioctl(struct drm_device *dev, void *data,
 			struct drm_file *file);
 
 /* i915_mm.c */
-int remap_io_mapping(struct vm_area_struct *vma,
-		     unsigned long addr, unsigned long pfn, unsigned long size,
-		     struct io_mapping *iomap);
 int remap_io_sg(struct vm_area_struct *vma,
 		unsigned long addr, unsigned long size,
 		struct scatterlist *sgl, resource_size_t iobase);
diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index 666808cb3a3260..9a777b0ff59b05 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -37,17 +37,6 @@ struct remap_pfn {
 	resource_size_t iobase;
 };
 
-static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
-{
-	struct remap_pfn *r = data;
-
-	/* Special PTE are not associated with any struct page */
-	set_pte_at(r->mm, addr, pte, pte_mkspecial(pfn_pte(r->pfn, r->prot)));
-	r->pfn++;
-
-	return 0;
-}
-
 #define use_dma(io) ((io) != -1)
 
 static inline unsigned long sgt_pfn(const struct remap_pfn *r)
@@ -77,40 +66,7 @@ static int remap_sg(pte_t *pte, unsigned long addr, void *data)
 	return 0;
 }
 
-/**
- * remap_io_mapping - remap an IO mapping to userspace
- * @vma: user vma to map to
- * @addr: target user address to start at
- * @pfn: physical address of kernel memory
- * @size: size of map area
- * @iomap: the source io_mapping
- *
- *  Note: this is only safe if the mm semaphore is held when called.
- */
-int remap_io_mapping(struct vm_area_struct *vma,
-		     unsigned long addr, unsigned long pfn, unsigned long size,
-		     struct io_mapping *iomap)
-{
-	struct remap_pfn r;
-	int err;
-
 #define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
-	GEM_BUG_ON((vma->vm_flags & EXPECTED_FLAGS) != EXPECTED_FLAGS);
-
-	/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
-	r.mm = vma->vm_mm;
-	r.pfn = pfn;
-	r.prot = __pgprot((pgprot_val(iomap->prot) & _PAGE_CACHE_MASK) |
-			  (pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK));
-
-	err = apply_to_page_range(r.mm, addr, size, remap_pfn, &r);
-	if (unlikely(err)) {
-		zap_vma_ptes(vma, addr, (r.pfn - pfn) << PAGE_SHIFT);
-		return err;
-	}
-
-	return 0;
-}
 
 /**
  * remap_io_sg - remap an IO mapping to userspace
-- 
2.30.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 63+ messages in thread

* [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
@ 2021-03-26  5:55   ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Chris Wilson, Daniel Vetter, Peter Zijlstra, intel-gfx,
	dri-devel, linux-mm

remap_io_sg claims that that the pgprot is pre-verified using an
io_mapping, but actually does not get passed an io_mapping and just
uses the pgprot in the VMA.  Remove the apply_to_page_range abuse
and just loop over remap_pfn_range for each segment.

Note: this could use io_mapping_map_user by passing an iomap to
remap_io_sg if the maintainers can verify that the pgprot in the
iomap in the only caller is indeed the desired one here.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/i915_mm.c | 73 +++++++++++-----------------------
 1 file changed, 23 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index 9a777b0ff59b05..4c8cd08c672d2d 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -28,46 +28,10 @@
 
 #include "i915_drv.h"
 
-struct remap_pfn {
-	struct mm_struct *mm;
-	unsigned long pfn;
-	pgprot_t prot;
-
-	struct sgt_iter sgt;
-	resource_size_t iobase;
-};
+#define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
 
 #define use_dma(io) ((io) != -1)
 
-static inline unsigned long sgt_pfn(const struct remap_pfn *r)
-{
-	if (use_dma(r->iobase))
-		return (r->sgt.dma + r->sgt.curr + r->iobase) >> PAGE_SHIFT;
-	else
-		return r->sgt.pfn + (r->sgt.curr >> PAGE_SHIFT);
-}
-
-static int remap_sg(pte_t *pte, unsigned long addr, void *data)
-{
-	struct remap_pfn *r = data;
-
-	if (GEM_WARN_ON(!r->sgt.sgp))
-		return -EINVAL;
-
-	/* Special PTE are not associated with any struct page */
-	set_pte_at(r->mm, addr, pte,
-		   pte_mkspecial(pfn_pte(sgt_pfn(r), r->prot)));
-	r->pfn++; /* track insertions in case we need to unwind later */
-
-	r->sgt.curr += PAGE_SIZE;
-	if (r->sgt.curr >= r->sgt.max)
-		r->sgt = __sgt_iter(__sg_next(r->sgt.sgp), use_dma(r->iobase));
-
-	return 0;
-}
-
-#define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
-
 /**
  * remap_io_sg - remap an IO mapping to userspace
  * @vma: user vma to map to
@@ -82,12 +46,7 @@ int remap_io_sg(struct vm_area_struct *vma,
 		unsigned long addr, unsigned long size,
 		struct scatterlist *sgl, resource_size_t iobase)
 {
-	struct remap_pfn r = {
-		.mm = vma->vm_mm,
-		.prot = vma->vm_page_prot,
-		.sgt = __sgt_iter(sgl, use_dma(iobase)),
-		.iobase = iobase,
-	};
+	unsigned long pfn, len, remapped = 0;
 	int err;
 
 	/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
@@ -96,11 +55,25 @@ int remap_io_sg(struct vm_area_struct *vma,
 	if (!use_dma(iobase))
 		flush_cache_range(vma, addr, size);
 
-	err = apply_to_page_range(r.mm, addr, size, remap_sg, &r);
-	if (unlikely(err)) {
-		zap_vma_ptes(vma, addr, r.pfn << PAGE_SHIFT);
-		return err;
-	}
-
-	return 0;
+	do {
+		if (use_dma(iobase)) {
+			if (!sg_dma_len(sgl))
+				break;
+			pfn = (sg_dma_address(sgl) + iobase) >> PAGE_SHIFT;
+			len = sg_dma_len(sgl);
+		} else {
+			pfn = page_to_pfn(sg_page(sgl));
+			len = sgl->length;
+		}
+
+		err = remap_pfn_range(vma, addr + remapped, pfn, len,
+				      vma->vm_page_prot);
+		if (err)
+			break;
+		remapped += len;
+	} while ((sgl = __sg_next(sgl)));
+
+	if (err)
+		zap_vma_ptes(vma, addr, remapped);
+	return err;
 }
-- 
2.30.1



^ permalink raw reply related	[flat|nested] 63+ messages in thread

* [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-03-26  5:55   ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-03-26  5:55 UTC (permalink / raw)
  To: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm

remap_io_sg claims that that the pgprot is pre-verified using an
io_mapping, but actually does not get passed an io_mapping and just
uses the pgprot in the VMA.  Remove the apply_to_page_range abuse
and just loop over remap_pfn_range for each segment.

Note: this could use io_mapping_map_user by passing an iomap to
remap_io_sg if the maintainers can verify that the pgprot in the
iomap in the only caller is indeed the desired one here.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/i915/i915_mm.c | 73 +++++++++++-----------------------
 1 file changed, 23 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index 9a777b0ff59b05..4c8cd08c672d2d 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -28,46 +28,10 @@
 
 #include "i915_drv.h"
 
-struct remap_pfn {
-	struct mm_struct *mm;
-	unsigned long pfn;
-	pgprot_t prot;
-
-	struct sgt_iter sgt;
-	resource_size_t iobase;
-};
+#define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
 
 #define use_dma(io) ((io) != -1)
 
-static inline unsigned long sgt_pfn(const struct remap_pfn *r)
-{
-	if (use_dma(r->iobase))
-		return (r->sgt.dma + r->sgt.curr + r->iobase) >> PAGE_SHIFT;
-	else
-		return r->sgt.pfn + (r->sgt.curr >> PAGE_SHIFT);
-}
-
-static int remap_sg(pte_t *pte, unsigned long addr, void *data)
-{
-	struct remap_pfn *r = data;
-
-	if (GEM_WARN_ON(!r->sgt.sgp))
-		return -EINVAL;
-
-	/* Special PTE are not associated with any struct page */
-	set_pte_at(r->mm, addr, pte,
-		   pte_mkspecial(pfn_pte(sgt_pfn(r), r->prot)));
-	r->pfn++; /* track insertions in case we need to unwind later */
-
-	r->sgt.curr += PAGE_SIZE;
-	if (r->sgt.curr >= r->sgt.max)
-		r->sgt = __sgt_iter(__sg_next(r->sgt.sgp), use_dma(r->iobase));
-
-	return 0;
-}
-
-#define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
-
 /**
  * remap_io_sg - remap an IO mapping to userspace
  * @vma: user vma to map to
@@ -82,12 +46,7 @@ int remap_io_sg(struct vm_area_struct *vma,
 		unsigned long addr, unsigned long size,
 		struct scatterlist *sgl, resource_size_t iobase)
 {
-	struct remap_pfn r = {
-		.mm = vma->vm_mm,
-		.prot = vma->vm_page_prot,
-		.sgt = __sgt_iter(sgl, use_dma(iobase)),
-		.iobase = iobase,
-	};
+	unsigned long pfn, len, remapped = 0;
 	int err;
 
 	/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
@@ -96,11 +55,25 @@ int remap_io_sg(struct vm_area_struct *vma,
 	if (!use_dma(iobase))
 		flush_cache_range(vma, addr, size);
 
-	err = apply_to_page_range(r.mm, addr, size, remap_sg, &r);
-	if (unlikely(err)) {
-		zap_vma_ptes(vma, addr, r.pfn << PAGE_SHIFT);
-		return err;
-	}
-
-	return 0;
+	do {
+		if (use_dma(iobase)) {
+			if (!sg_dma_len(sgl))
+				break;
+			pfn = (sg_dma_address(sgl) + iobase) >> PAGE_SHIFT;
+			len = sg_dma_len(sgl);
+		} else {
+			pfn = page_to_pfn(sg_page(sgl));
+			len = sgl->length;
+		}
+
+		err = remap_pfn_range(vma, addr + remapped, pfn, len,
+				      vma->vm_page_prot);
+		if (err)
+			break;
+		remapped += len;
+	} while ((sgl = __sg_next(sgl)));
+
+	if (err)
+		zap_vma_ptes(vma, addr, remapped);
+	return err;
 }
-- 
2.30.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 63+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] mm: add remap_pfn_range_notrack
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
                   ` (4 preceding siblings ...)
  (?)
@ 2021-03-26  7:28 ` Patchwork
  -1 siblings, 0 replies; 63+ messages in thread
From: Patchwork @ 2021-03-26  7:28 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/4] mm: add remap_pfn_range_notrack
URL   : https://patchwork.freedesktop.org/series/88472/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e3d889b6653b mm: add remap_pfn_range_notrack
-:21: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#21: FILE: include/linux/mm.h:2713:
+int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr,
+		unsigned long pfn, unsigned long size, pgprot_t prot);

-:51: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#51: FILE: mm/memory.c:2268:
+int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr,
+		unsigned long pfn, unsigned long size, pgprot_t prot)

total: 0 errors, 0 warnings, 2 checks, 87 lines checked
9afcebc072dd mm: add a io_mapping_map_user helper
-:22: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#22: FILE: include/linux/io-mapping.h:225:
+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
+		unsigned long addr, unsigned long pfn, unsigned long size);

-:45: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#45: 
new file mode 100644

-:66: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#66: FILE: mm/io-mapping.c:17:
+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
+		unsigned long addr, unsigned long pfn, unsigned long size)

total: 0 errors, 1 warnings, 2 checks, 46 lines checked
22d2aa9b1a1e i915: use io_mapping_map_user
7452c4f8f8ac i915: fix remap_io_sg to verify the pgprot
-:6: WARNING:REPEATED_WORD: Possible repeated word: 'that'
#6: 
remap_io_sg claims that that the pgprot is pre-verified using an

total: 0 errors, 1 warnings, 0 checks, 92 lines checked


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] mm: add remap_pfn_range_notrack
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
                   ` (5 preceding siblings ...)
  (?)
@ 2021-03-26  7:31 ` Patchwork
  -1 siblings, 0 replies; 63+ messages in thread
From: Patchwork @ 2021-03-26  7:31 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/4] mm: add remap_pfn_range_notrack
URL   : https://patchwork.freedesktop.org/series/88472/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1399:25: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1399:25:    struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1399:25:    struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1400:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1400:17:    struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1400:17:    struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1459:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1459:17:    struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1459:17:    struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:284:16: error: incompatible types in comparison expression (different type sizes):
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:284:16:    unsigned long *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:284:16:    unsigned long long *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:276:25: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:276:25:    struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:276:25:    struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:277:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:277:17:    struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:277:17:    struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:331:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:331:17:    struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:331:17:    struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.h:92:56: error: marked inline, but without a definition
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/a


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/4] mm: add remap_pfn_range_notrack
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
                   ` (6 preceding siblings ...)
  (?)
@ 2021-03-26  7:34 ` Patchwork
  -1 siblings, 0 replies; 63+ messages in thread
From: Patchwork @ 2021-03-26  7:34 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/4] mm: add remap_pfn_range_notrack
URL   : https://patchwork.freedesktop.org/series/88472/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser'
/home/cidrm/kernel/Documentation/gpu/i915:22: ./drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-string.


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] mm: add remap_pfn_range_notrack
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
                   ` (7 preceding siblings ...)
  (?)
@ 2021-03-26  7:59 ` Patchwork
  -1 siblings, 0 replies; 63+ messages in thread
From: Patchwork @ 2021-03-26  7:59 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 22849 bytes --]

== Series Details ==

Series: series starting with [1/4] mm: add remap_pfn_range_notrack
URL   : https://patchwork.freedesktop.org/series/88472/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9902 -> Patchwork_19864
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_19864 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_19864, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_19864:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_exec_fence@nb-await@vecs0:
    - fi-bsw-nick:        [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bsw-nick/igt@gem_exec_fence@nb-await@vecs0.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bsw-nick/igt@gem_exec_fence@nb-await@vecs0.html

  * igt@i915_module_load@reload:
    - fi-icl-u2:          [PASS][3] -> [DMESG-WARN][4] +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-icl-u2/igt@i915_module_load@reload.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-icl-u2/igt@i915_module_load@reload.html
    - fi-cml-u2:          [PASS][5] -> [DMESG-WARN][6] +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-cml-u2/igt@i915_module_load@reload.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-cml-u2/igt@i915_module_load@reload.html
    - fi-cfl-8700k:       [PASS][7] -> [DMESG-WARN][8] +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-cfl-8700k/igt@i915_module_load@reload.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-cfl-8700k/igt@i915_module_load@reload.html
    - fi-snb-2520m:       [PASS][9] -> [DMESG-WARN][10] +1 similar issue
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-snb-2520m/igt@i915_module_load@reload.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-snb-2520m/igt@i915_module_load@reload.html
    - fi-bxt-dsi:         [PASS][11] -> [DMESG-WARN][12] +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bxt-dsi/igt@i915_module_load@reload.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bxt-dsi/igt@i915_module_load@reload.html
    - fi-hsw-4770:        [PASS][13] -> [DMESG-WARN][14] +1 similar issue
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-hsw-4770/igt@i915_module_load@reload.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-hsw-4770/igt@i915_module_load@reload.html
    - fi-cml-s:           [PASS][15] -> [DMESG-WARN][16] +1 similar issue
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-cml-s/igt@i915_module_load@reload.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-cml-s/igt@i915_module_load@reload.html
    - fi-pnv-d510:        [PASS][17] -> [DMESG-WARN][18] +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-pnv-d510/igt@i915_module_load@reload.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-pnv-d510/igt@i915_module_load@reload.html
    - fi-skl-6600u:       [PASS][19] -> [DMESG-WARN][20] +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-skl-6600u/igt@i915_module_load@reload.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-skl-6600u/igt@i915_module_load@reload.html
    - fi-cfl-guc:         [PASS][21] -> [DMESG-WARN][22] +1 similar issue
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-cfl-guc/igt@i915_module_load@reload.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-cfl-guc/igt@i915_module_load@reload.html
    - fi-ilk-650:         [PASS][23] -> [DMESG-FAIL][24] +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-ilk-650/igt@i915_module_load@reload.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-ilk-650/igt@i915_module_load@reload.html
    - fi-ivb-3770:        [PASS][25] -> [DMESG-WARN][26] +1 similar issue
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-ivb-3770/igt@i915_module_load@reload.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-ivb-3770/igt@i915_module_load@reload.html
    - fi-elk-e7500:       [PASS][27] -> [DMESG-FAIL][28] +1 similar issue
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-elk-e7500/igt@i915_module_load@reload.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-elk-e7500/igt@i915_module_load@reload.html
    - fi-skl-6700k2:      [PASS][29] -> [DMESG-WARN][30] +1 similar issue
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-skl-6700k2/igt@i915_module_load@reload.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-skl-6700k2/igt@i915_module_load@reload.html
    - fi-kbl-x1275:       [PASS][31] -> [DMESG-WARN][32] +1 similar issue
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-kbl-x1275/igt@i915_module_load@reload.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-kbl-x1275/igt@i915_module_load@reload.html
    - fi-kbl-guc:         [PASS][33] -> [DMESG-WARN][34] +1 similar issue
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-kbl-guc/igt@i915_module_load@reload.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-kbl-guc/igt@i915_module_load@reload.html
    - fi-bsw-nick:        [PASS][35] -> [DMESG-FAIL][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bsw-nick/igt@i915_module_load@reload.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bsw-nick/igt@i915_module_load@reload.html

  * igt@i915_selftest@live@mman:
    - fi-bsw-kefka:       [PASS][37] -> [DMESG-WARN][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bsw-kefka/igt@i915_selftest@live@mman.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bsw-kefka/igt@i915_selftest@live@mman.html
    - fi-bwr-2160:        [PASS][39] -> [DMESG-FAIL][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bwr-2160/igt@i915_selftest@live@mman.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bwr-2160/igt@i915_selftest@live@mman.html
    - fi-kbl-r:           [PASS][41] -> [DMESG-WARN][42] +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-kbl-r/igt@i915_selftest@live@mman.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-kbl-r/igt@i915_selftest@live@mman.html
    - fi-bsw-nick:        [PASS][43] -> [DMESG-WARN][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bsw-nick/igt@i915_selftest@live@mman.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bsw-nick/igt@i915_selftest@live@mman.html
    - fi-bdw-5557u:       NOTRUN -> [DMESG-WARN][45] +1 similar issue
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bdw-5557u/igt@i915_selftest@live@mman.html
    - fi-kbl-soraka:      [PASS][46] -> [DMESG-WARN][47]
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-kbl-soraka/igt@i915_selftest@live@mman.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-kbl-soraka/igt@i915_selftest@live@mman.html
    - fi-cfl-8109u:       [PASS][48] -> [DMESG-WARN][49] +1 similar issue
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-cfl-8109u/igt@i915_selftest@live@mman.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-cfl-8109u/igt@i915_selftest@live@mman.html
    - fi-snb-2600:        [PASS][50] -> [DMESG-WARN][51] +1 similar issue
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-snb-2600/igt@i915_selftest@live@mman.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-snb-2600/igt@i915_selftest@live@mman.html
    - fi-byt-j1900:       [PASS][52] -> [DMESG-FAIL][53]
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-byt-j1900/igt@i915_selftest@live@mman.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-byt-j1900/igt@i915_selftest@live@mman.html
    - fi-tgl-u2:          [PASS][54] -> [DMESG-WARN][55]
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-tgl-u2/igt@i915_selftest@live@mman.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-tgl-u2/igt@i915_selftest@live@mman.html
    - fi-skl-guc:         [PASS][56] -> [DMESG-WARN][57] +1 similar issue
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-skl-guc/igt@i915_selftest@live@mman.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-skl-guc/igt@i915_selftest@live@mman.html
    - fi-kbl-7567u:       [PASS][58] -> [DMESG-WARN][59] +1 similar issue
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-kbl-7567u/igt@i915_selftest@live@mman.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-kbl-7567u/igt@i915_selftest@live@mman.html
    - fi-glk-dsi:         [PASS][60] -> [DMESG-WARN][61]
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-glk-dsi/igt@i915_selftest@live@mman.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-glk-dsi/igt@i915_selftest@live@mman.html
    - fi-tgl-y:           [PASS][62] -> [DMESG-WARN][63]
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-tgl-y/igt@i915_selftest@live@mman.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-tgl-y/igt@i915_selftest@live@mman.html
    - fi-kbl-7500u:       [PASS][64] -> [DMESG-WARN][65] +1 similar issue
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-kbl-7500u/igt@i915_selftest@live@mman.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-kbl-7500u/igt@i915_selftest@live@mman.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-byt-j1900:       [PASS][66] -> [FAIL][67] +3 similar issues
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-byt-j1900/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-byt-j1900/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
    - fi-bxt-dsi:         [PASS][68] -> [FAIL][69] +3 similar issues
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bxt-dsi/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bxt-dsi/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - fi-bsw-kefka:       [PASS][70] -> [FAIL][71] +5 similar issues
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
    - fi-pnv-d510:        [PASS][72] -> [FAIL][73] +2 similar issues
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-pnv-d510/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-pnv-d510/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
    - fi-glk-dsi:         [PASS][74] -> [FAIL][75] +4 similar issues
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-glk-dsi/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-glk-dsi/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
    - fi-bwr-2160:        [PASS][76] -> [FAIL][77] +1 similar issue
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bwr-2160/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bwr-2160/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
    - fi-ilk-650:         [PASS][78] -> [FAIL][79] +16 similar issues
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-ilk-650/igt@kms_pipe_crc_basic@hang-read-crc-pipe-a.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-ilk-650/igt@kms_pipe_crc_basic@hang-read-crc-pipe-a.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
    - fi-elk-e7500:       [PASS][80] -> [FAIL][81] +8 similar issues
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-elk-e7500/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-elk-e7500/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence.html

  
#### Warnings ####

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
    - fi-glk-dsi:         [DMESG-WARN][82] ([i915#3143]) -> [DMESG-FAIL][83]
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-glk-dsi/igt@kms_pipe_crc_basic@read-crc-pipe-b.html
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-glk-dsi/igt@kms_pipe_crc_basic@read-crc-pipe-b.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_module_load@reload:
    - {fi-hsw-gt1}:       [PASS][84] -> [DMESG-WARN][85] +1 similar issue
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-hsw-gt1/igt@i915_module_load@reload.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-hsw-gt1/igt@i915_module_load@reload.html
    - {fi-ehl-1}:         [PASS][86] -> [DMESG-WARN][87]
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-ehl-1/igt@i915_module_load@reload.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-ehl-1/igt@i915_module_load@reload.html

  * igt@i915_selftest@live@mman:
    - {fi-ehl-1}:         NOTRUN -> [DMESG-WARN][88]
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-ehl-1/igt@i915_selftest@live@mman.html
    - {fi-tgl-dsi}:       [PASS][89] -> [DMESG-WARN][90]
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-tgl-dsi/igt@i915_selftest@live@mman.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-tgl-dsi/igt@i915_selftest@live@mman.html

  * igt@kms_frontbuffer_tracking@basic:
    - {fi-rkl-11500t}:    [FAIL][91] ([i915#3278]) -> [INCOMPLETE][92]
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-rkl-11500t/igt@kms_frontbuffer_tracking@basic.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-rkl-11500t/igt@kms_frontbuffer_tracking@basic.html

  * igt@runner@aborted:
    - {fi-rkl-11500t}:    NOTRUN -> [FAIL][93]
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-rkl-11500t/igt@runner@aborted.html

  
Known issues
------------

  Here are the changes found in Patchwork_19864 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@semaphore:
    - fi-bdw-5557u:       NOTRUN -> [SKIP][94] ([fdo#109271]) +27 similar issues
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bdw-5557u/igt@amdgpu/amd_basic@semaphore.html

  * igt@core_hotunplug@unbind-rebind:
    - fi-bdw-5557u:       NOTRUN -> [WARN][95] ([i915#2283])
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bdw-5557u/igt@core_hotunplug@unbind-rebind.html

  * igt@gem_wait@busy@all:
    - fi-bsw-kefka:       [PASS][96] -> [FAIL][97] ([i915#3177])
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bsw-kefka/igt@gem_wait@busy@all.html
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bsw-kefka/igt@gem_wait@busy@all.html

  * igt@i915_module_load@reload:
    - fi-byt-j1900:       [PASS][98] -> [DMESG-WARN][99] ([i915#1982])
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-byt-j1900/igt@i915_module_load@reload.html
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-byt-j1900/igt@i915_module_load@reload.html
    - fi-kbl-soraka:      [PASS][100] -> [DMESG-WARN][101] ([i915#1982])
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-kbl-soraka/igt@i915_module_load@reload.html
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-kbl-soraka/igt@i915_module_load@reload.html
    - fi-tgl-u2:          [PASS][102] -> [DMESG-WARN][103] ([k.org#205379])
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-tgl-u2/igt@i915_module_load@reload.html
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-tgl-u2/igt@i915_module_load@reload.html
    - fi-bsw-kefka:       [PASS][104] -> [DMESG-WARN][105] ([i915#1982])
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-bsw-kefka/igt@i915_module_load@reload.html
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bsw-kefka/igt@i915_module_load@reload.html
    - fi-tgl-y:           [PASS][106] -> [DMESG-WARN][107] ([i915#1982] / [k.org#205379])
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-tgl-y/igt@i915_module_load@reload.html
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-tgl-y/igt@i915_module_load@reload.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-icl-u2:          [PASS][108] -> [DMESG-WARN][109] ([i915#2203] / [i915#2868])
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
    - fi-bdw-5557u:       NOTRUN -> [SKIP][110] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-bdw-5557u/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - fi-byt-j1900:       [PASS][111] -> [FAIL][112] ([i915#53]) +1 similar issue
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-byt-j1900/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-byt-j1900/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
    - fi-tgl-y:           [PASS][113] -> [DMESG-WARN][114] ([i915#402])
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  
#### Possible fixes ####

  * igt@i915_pm_rpm@module-reload:
    - {fi-ehl-1}:         [INCOMPLETE][115] ([i915#2405]) -> [PASS][116]
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-ehl-1/igt@i915_pm_rpm@module-reload.html
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-ehl-1/igt@i915_pm_rpm@module-reload.html

  * igt@prime_self_import@basic-with_one_bo:
    - fi-tgl-y:           [DMESG-WARN][117] ([i915#402]) -> [PASS][118] +2 similar issues
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html

  
#### Warnings ####

  * igt@i915_module_load@reload:
    - fi-glk-dsi:         [DMESG-WARN][119] ([i915#3143]) -> [DMESG-FAIL][120] ([i915#1982])
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-glk-dsi/igt@i915_module_load@reload.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-glk-dsi/igt@i915_module_load@reload.html

  * igt@i915_pm_rpm@module-reload:
    - fi-glk-dsi:         [DMESG-WARN][121] ([i915#1982] / [i915#3143]) -> [DMESG-WARN][122] ([i915#3143])
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9902/fi-glk-dsi/igt@i915_pm_rpm@module-reload.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/fi-glk-dsi/igt@i915_pm_rpm@module-reload.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1021]: https://gitlab.freedesktop.org/drm/intel/issues/1021
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
  [i915#3143]: https://gitlab.freedesktop.org/drm/intel/issues/3143
  [i915#3177]: https://gitlab.freedesktop.org/drm/intel/issues/3177
  [i915#3278]: https://gitlab.freedesktop.org/drm/intel/issues/3278
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#53]: https://gitlab.freedesktop.org/drm/intel/issues/53
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (46 -> 42)
------------------------------

  Additional (1): fi-bdw-5557u 
  Missing    (5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-icl-y fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9902 -> Patchwork_19864

  CI-20190529: 20190529
  CI_DRM_9902: 356ce79a30960181dc8d810c5072a9108aa24f1d @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6046: e76039273b1524147c43dba061756f06003d56ae @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19864: 7452c4f8f8ac802a265cc629ce51d3b8d7b3bce3 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

7452c4f8f8ac i915: fix remap_io_sg to verify the pgprot
22d2aa9b1a1e i915: use io_mapping_map_user
9afcebc072dd mm: add a io_mapping_map_user helper
e3d889b6653b mm: add remap_pfn_range_notrack

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19864/index.html

[-- Attachment #1.2: Type: text/html, Size: 25265 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: add remap_pfn_range_notrack instead of reinventing it in i915 v2
  2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2021-04-08 10:36   ` Daniel Vetter
  -1 siblings, 0 replies; 63+ messages in thread
From: Daniel Vetter @ 2021-04-08 10:36 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
	Chris Wilson, Daniel Vetter, Peter Zijlstra, intel-gfx,
	dri-devel, linux-mm

On Fri, Mar 26, 2021 at 06:55:01AM +0100, Christoph Hellwig wrote:
> Hi all,
> 
> i915 has some reason to want to avoid the track_pfn_remap overhead in
> remap_pfn_range.  Add a function to the core VM to do just that rather
> than reinventing the functionality poorly in the driver.
> 
> Note that the remap_io_sg path does get exercises when using Xorg on my
> Thinkpad X1, so this should be considered lightly tested, I've not
> managed to hit the remap_io_mapping path at all.
> 
> Changes since v1:
>  - create a io_mapping_map_user wrapper instead of exporting
>    remap_pfn_range_notrack
>  - switch to plain remap_pfn_range for remap_sg as it does not use
>    a pre-verified pgprot from an iomap

I'm burried under patches and stuff so no in-depth review. But from a
quick scan lgtm. On the series:

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I've seen it's landed already in some tree, maybe if you can add the acks
ftr?

Cheers, Daniel

> 
> Diffstat:
>  drivers/gpu/drm/i915/Kconfig             |    1 
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c |    9 +-
>  drivers/gpu/drm/i915/i915_drv.h          |    3 
>  drivers/gpu/drm/i915/i915_mm.c           |  117 ++++++-------------------------
>  include/linux/io-mapping.h               |    3 
>  include/linux/mm.h                       |    2 
>  mm/Kconfig                               |    3 
>  mm/Makefile                              |    1 
>  mm/io-mapping.c                          |   29 +++++++
>  mm/memory.c                              |   51 ++++++++-----
>  10 files changed, 97 insertions(+), 122 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: add remap_pfn_range_notrack instead of reinventing it in i915 v2
@ 2021-04-08 10:36   ` Daniel Vetter
  0 siblings, 0 replies; 63+ messages in thread
From: Daniel Vetter @ 2021-04-08 10:36 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Rodrigo Vivi, Andrew Morton

On Fri, Mar 26, 2021 at 06:55:01AM +0100, Christoph Hellwig wrote:
> Hi all,
> 
> i915 has some reason to want to avoid the track_pfn_remap overhead in
> remap_pfn_range.  Add a function to the core VM to do just that rather
> than reinventing the functionality poorly in the driver.
> 
> Note that the remap_io_sg path does get exercises when using Xorg on my
> Thinkpad X1, so this should be considered lightly tested, I've not
> managed to hit the remap_io_mapping path at all.
> 
> Changes since v1:
>  - create a io_mapping_map_user wrapper instead of exporting
>    remap_pfn_range_notrack
>  - switch to plain remap_pfn_range for remap_sg as it does not use
>    a pre-verified pgprot from an iomap

I'm burried under patches and stuff so no in-depth review. But from a
quick scan lgtm. On the series:

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I've seen it's landed already in some tree, maybe if you can add the acks
ftr?

Cheers, Daniel

> 
> Diffstat:
>  drivers/gpu/drm/i915/Kconfig             |    1 
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c |    9 +-
>  drivers/gpu/drm/i915/i915_drv.h          |    3 
>  drivers/gpu/drm/i915/i915_mm.c           |  117 ++++++-------------------------
>  include/linux/io-mapping.h               |    3 
>  include/linux/mm.h                       |    2 
>  mm/Kconfig                               |    3 
>  mm/Makefile                              |    1 
>  mm/io-mapping.c                          |   29 +++++++
>  mm/memory.c                              |   51 ++++++++-----
>  10 files changed, 97 insertions(+), 122 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] add remap_pfn_range_notrack instead of reinventing it in i915 v2
@ 2021-04-08 10:36   ` Daniel Vetter
  0 siblings, 0 replies; 63+ messages in thread
From: Daniel Vetter @ 2021-04-08 10:36 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Andrew Morton

On Fri, Mar 26, 2021 at 06:55:01AM +0100, Christoph Hellwig wrote:
> Hi all,
> 
> i915 has some reason to want to avoid the track_pfn_remap overhead in
> remap_pfn_range.  Add a function to the core VM to do just that rather
> than reinventing the functionality poorly in the driver.
> 
> Note that the remap_io_sg path does get exercises when using Xorg on my
> Thinkpad X1, so this should be considered lightly tested, I've not
> managed to hit the remap_io_mapping path at all.
> 
> Changes since v1:
>  - create a io_mapping_map_user wrapper instead of exporting
>    remap_pfn_range_notrack
>  - switch to plain remap_pfn_range for remap_sg as it does not use
>    a pre-verified pgprot from an iomap

I'm burried under patches and stuff so no in-depth review. But from a
quick scan lgtm. On the series:

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I've seen it's landed already in some tree, maybe if you can add the acks
ftr?

Cheers, Daniel

> 
> Diffstat:
>  drivers/gpu/drm/i915/Kconfig             |    1 
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c |    9 +-
>  drivers/gpu/drm/i915/i915_drv.h          |    3 
>  drivers/gpu/drm/i915/i915_mm.c           |  117 ++++++-------------------------
>  include/linux/io-mapping.h               |    3 
>  include/linux/mm.h                       |    2 
>  mm/Kconfig                               |    3 
>  mm/Makefile                              |    1 
>  mm/io-mapping.c                          |   29 +++++++
>  mm/memory.c                              |   51 ++++++++-----
>  10 files changed, 97 insertions(+), 122 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: add remap_pfn_range_notrack instead of reinventing it in i915 v2
  2021-04-08 10:36   ` Daniel Vetter
@ 2021-04-08 11:28     ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-04-08 11:28 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi, Chris Wilson, Peter Zijlstra, intel-gfx, dri-devel,
	linux-mm

On Thu, Apr 08, 2021 at 12:36:21PM +0200, Daniel Vetter wrote:
> I've seen it's landed already in some tree, maybe if you can add the acks
> ftr?

Andrew has picked it up in -mm.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] add remap_pfn_range_notrack instead of reinventing it in i915 v2
@ 2021-04-08 11:28     ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-04-08 11:28 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi, Chris Wilson, Peter Zijlstra, intel-gfx, dri-devel,
	linux-mm

On Thu, Apr 08, 2021 at 12:36:21PM +0200, Daniel Vetter wrote:
> I've seen it's landed already in some tree, maybe if you can add the acks
> ftr?

Andrew has picked it up in -mm.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-03-26  5:55   ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2021-05-08 19:33     ` youling257
  -1 siblings, 0 replies; 63+ messages in thread
From: youling257 @ 2021-05-08 19:33 UTC (permalink / raw)
  To: hch
  Cc: akpm, chris, daniel.vetter, dri-devel, intel-gfx, jani.nikula,
	joonas.lahtinen, linux-mm, peterz, rodrigo.vivi

This patch cause "x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back" problem.
my 2GB ram Bay trail z3735f tablet runing on android-x86, "i915: fix remap_io_sg to verify the pgprot" cause this problem.

05-09 02:59:25.099     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0640a000-0x0640dfff], got write-back
05-09 02:59:25.106  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.111     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back
05-09 02:59:25.118     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06400000-0x06404fff], got write-back
05-09 02:59:25.125     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06405000-0x06408fff], got write-back
05-09 02:59:25.148  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.158     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06542000-0x06542fff], got write-back
05-09 02:59:25.165     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06499000-0x0649dfff], got write-back
05-09 02:59:25.171     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0649e000-0x064a1fff], got write-back
05-09 02:59:25.177  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.183     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065fa000-0x065fafff], got write-back
05-09 02:59:25.192     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06539000-0x0653dfff], got write-back
05-09 02:59:25.199     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0653e000-0x06541fff], got write-back
05-09 02:59:25.204  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.212     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x066a2000-0x066a2fff], got write-back
05-09 02:59:25.218     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065f1000-0x065f5fff], got write-back
05-09 02:59:25.226     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065f6000-0x065f9fff], got write-back


05-09 02:59:27.101     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08a76000-0x08a76fff], got write-back
05-09 02:59:27.225     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08a77000-0x08a7afff], got write-back
05-09 02:59:27.242     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08bd0000-0x08bd0fff], got write-back
05-09 02:59:27.254     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08bd1000-0x08bf0fff], got write-back
05-09 02:59:27.310  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.322     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x080d5000-0x080d9fff], got write-back
05-09 02:59:27.322     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x080da000-0x080ddfff], got write-back
05-09 02:59:27.338     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x1b830000-0x1b83ffff], got write-back
05-09 02:59:27.338     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x1b76a000-0x1b76efff], got write-back
05-09 02:59:27.344     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x07e87000-0x07e8bfff], got write-back
05-09 02:59:27.349     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x07e8c000-0x07e90fff], got write-back
05-09 02:59:27.347  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.361     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c123000-0x1c126fff], got write-back
05-09 02:59:27.361     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c127000-0x1c12afff], got write-back
05-09 02:59:27.362     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c12f000-0x1c13efff], got write-back
05-09 02:59:27.362     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c12b000-0x1c12efff], got write-back
05-09 02:59:27.364  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.377     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c140000-0x1c144fff], got write-back
05-09 02:59:27.377     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c145000-0x1c148fff], got write-back
05-09 02:59:27.378     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c14b000-0x1c14ffff], got write-back
05-09 02:59:27.379     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c151000-0x1c155fff], got write-back
05-09 02:59:27.377  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.393     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c157000-0x1c15bfff], got write-back


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-08 19:33     ` youling257
  0 siblings, 0 replies; 63+ messages in thread
From: youling257 @ 2021-05-08 19:33 UTC (permalink / raw)
  To: hch
  Cc: peterz, daniel.vetter, intel-gfx, chris, linux-mm, dri-devel,
	rodrigo.vivi, akpm

This patch cause "x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back" problem.
my 2GB ram Bay trail z3735f tablet runing on android-x86, "i915: fix remap_io_sg to verify the pgprot" cause this problem.

05-09 02:59:25.099     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0640a000-0x0640dfff], got write-back
05-09 02:59:25.106  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.111     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back
05-09 02:59:25.118     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06400000-0x06404fff], got write-back
05-09 02:59:25.125     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06405000-0x06408fff], got write-back
05-09 02:59:25.148  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.158     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06542000-0x06542fff], got write-back
05-09 02:59:25.165     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06499000-0x0649dfff], got write-back
05-09 02:59:25.171     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0649e000-0x064a1fff], got write-back
05-09 02:59:25.177  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.183     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065fa000-0x065fafff], got write-back
05-09 02:59:25.192     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06539000-0x0653dfff], got write-back
05-09 02:59:25.199     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0653e000-0x06541fff], got write-back
05-09 02:59:25.204  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.212     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x066a2000-0x066a2fff], got write-back
05-09 02:59:25.218     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065f1000-0x065f5fff], got write-back
05-09 02:59:25.226     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065f6000-0x065f9fff], got write-back


05-09 02:59:27.101     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08a76000-0x08a76fff], got write-back
05-09 02:59:27.225     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08a77000-0x08a7afff], got write-back
05-09 02:59:27.242     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08bd0000-0x08bd0fff], got write-back
05-09 02:59:27.254     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08bd1000-0x08bf0fff], got write-back
05-09 02:59:27.310  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.322     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x080d5000-0x080d9fff], got write-back
05-09 02:59:27.322     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x080da000-0x080ddfff], got write-back
05-09 02:59:27.338     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x1b830000-0x1b83ffff], got write-back
05-09 02:59:27.338     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x1b76a000-0x1b76efff], got write-back
05-09 02:59:27.344     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x07e87000-0x07e8bfff], got write-back
05-09 02:59:27.349     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x07e8c000-0x07e90fff], got write-back
05-09 02:59:27.347  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.361     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c123000-0x1c126fff], got write-back
05-09 02:59:27.361     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c127000-0x1c12afff], got write-back
05-09 02:59:27.362     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c12f000-0x1c13efff], got write-back
05-09 02:59:27.362     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c12b000-0x1c12efff], got write-back
05-09 02:59:27.364  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.377     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c140000-0x1c144fff], got write-back
05-09 02:59:27.377     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c145000-0x1c148fff], got write-back
05-09 02:59:27.378     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c14b000-0x1c14ffff], got write-back
05-09 02:59:27.379     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c151000-0x1c155fff], got write-back
05-09 02:59:27.377  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.393     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c157000-0x1c15bfff], got write-back

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-08 19:33     ` youling257
  0 siblings, 0 replies; 63+ messages in thread
From: youling257 @ 2021-05-08 19:33 UTC (permalink / raw)
  To: hch; +Cc: peterz, daniel.vetter, intel-gfx, chris, linux-mm, dri-devel, akpm

This patch cause "x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back" problem.
my 2GB ram Bay trail z3735f tablet runing on android-x86, "i915: fix remap_io_sg to verify the pgprot" cause this problem.

05-09 02:59:25.099     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0640a000-0x0640dfff], got write-back
05-09 02:59:25.106  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.111     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back
05-09 02:59:25.118     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06400000-0x06404fff], got write-back
05-09 02:59:25.125     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06405000-0x06408fff], got write-back
05-09 02:59:25.148  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.158     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06542000-0x06542fff], got write-back
05-09 02:59:25.165     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06499000-0x0649dfff], got write-back
05-09 02:59:25.171     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0649e000-0x064a1fff], got write-back
05-09 02:59:25.177  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.183     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065fa000-0x065fafff], got write-back
05-09 02:59:25.192     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x06539000-0x0653dfff], got write-back
05-09 02:59:25.199     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x0653e000-0x06541fff], got write-back
05-09 02:59:25.204  1440  1440 W hwc-gl-worker: EGL_ANDROID_native_fence_sync extension not supported
05-09 02:59:25.212     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x066a2000-0x066a2fff], got write-back
05-09 02:59:25.218     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065f1000-0x065f5fff], got write-back
05-09 02:59:25.226     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x065f6000-0x065f9fff], got write-back


05-09 02:59:27.101     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08a76000-0x08a76fff], got write-back
05-09 02:59:27.225     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08a77000-0x08a7afff], got write-back
05-09 02:59:27.242     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08bd0000-0x08bd0fff], got write-back
05-09 02:59:27.254     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x08bd1000-0x08bf0fff], got write-back
05-09 02:59:27.310  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.322     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x080d5000-0x080d9fff], got write-back
05-09 02:59:27.322     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x080da000-0x080ddfff], got write-back
05-09 02:59:27.338     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x1b830000-0x1b83ffff], got write-back
05-09 02:59:27.338     0     0 W x86/PAT : BootAnimation:1665 map pfn RAM range req write-combining for [mem 0x1b76a000-0x1b76efff], got write-back
05-09 02:59:27.344     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x07e87000-0x07e8bfff], got write-back
05-09 02:59:27.349     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x07e8c000-0x07e90fff], got write-back
05-09 02:59:27.347  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.361     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c123000-0x1c126fff], got write-back
05-09 02:59:27.361     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c127000-0x1c12afff], got write-back
05-09 02:59:27.362     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c12f000-0x1c13efff], got write-back
05-09 02:59:27.362     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c12b000-0x1c12efff], got write-back
05-09 02:59:27.364  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.377     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c140000-0x1c144fff], got write-back
05-09 02:59:27.377     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c145000-0x1c148fff], got write-back
05-09 02:59:27.378     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c14b000-0x1c14ffff], got write-back
05-09 02:59:27.379     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c151000-0x1c155fff], got write-back
05-09 02:59:27.377  1440  1440 E drm-fb  : Failed to get handle from prime fd: 25
05-09 02:59:27.393     0     0 W x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x1c157000-0x1c15bfff], got write-back
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-08 19:33     ` youling257
@ 2021-05-10  8:58       ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-10  8:58 UTC (permalink / raw)
  To: youling257
  Cc: hch, akpm, chris, daniel.vetter, dri-devel, intel-gfx,
	jani.nikula, joonas.lahtinen, linux-mm, peterz, rodrigo.vivi

On Sun, May 09, 2021 at 03:33:29AM +0800, youling257 wrote:
> This patch cause "x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back" problem.
> my 2GB ram Bay trail z3735f tablet runing on android-x86, "i915: fix remap_io_sg to verify the pgprot" cause this problem.

So this is the memtype verification added by the patch, meaning that the
old code did in fact not call into track_pfn_remap with the right flags.

Can the i915 maintainers take a look at making sure the page permissions
here make sense?


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-10  8:58       ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-10  8:58 UTC (permalink / raw)
  To: youling257
  Cc: peterz, daniel.vetter, intel-gfx, dri-devel, chris, linux-mm, akpm, hch

On Sun, May 09, 2021 at 03:33:29AM +0800, youling257 wrote:
> This patch cause "x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back" problem.
> my 2GB ram Bay trail z3735f tablet runing on android-x86, "i915: fix remap_io_sg to verify the pgprot" cause this problem.

So this is the memtype verification added by the patch, meaning that the
old code did in fact not call into track_pfn_remap with the right flags.

Can the i915 maintainers take a look at making sure the page permissions
here make sense?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-03-26  5:55   ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2021-05-16 16:06     ` Serge Belyshev
  -1 siblings, 0 replies; 63+ messages in thread
From: Serge Belyshev @ 2021-05-16 16:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
	Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm

I have another problem with this patch since it landed in mainline. On
my m3-6Y30 skylake HD Graphics 515 (rev 07), it causes visual artifacts
that look like bunch of one pixel high horizontal streaks, seen most
often in firefox while scrolling or in menu controls.

Reverting this patch on top of current mainline fixes the problem.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-16 16:06     ` Serge Belyshev
  0 siblings, 0 replies; 63+ messages in thread
From: Serge Belyshev @ 2021-05-16 16:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Rodrigo Vivi, Andrew Morton

I have another problem with this patch since it landed in mainline. On
my m3-6Y30 skylake HD Graphics 515 (rev 07), it causes visual artifacts
that look like bunch of one pixel high horizontal streaks, seen most
often in firefox while scrolling or in menu controls.

Reverting this patch on top of current mainline fixes the problem.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-16 16:06     ` Serge Belyshev
  0 siblings, 0 replies; 63+ messages in thread
From: Serge Belyshev @ 2021-05-16 16:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Andrew Morton

I have another problem with this patch since it landed in mainline. On
my m3-6Y30 skylake HD Graphics 515 (rev 07), it causes visual artifacts
that look like bunch of one pixel high horizontal streaks, seen most
often in firefox while scrolling or in menu controls.

Reverting this patch on top of current mainline fixes the problem.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-16 16:06     ` Serge Belyshev
@ 2021-05-17 12:37       ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-17 12:37 UTC (permalink / raw)
  To: Serge Belyshev
  Cc: Christoph Hellwig, Andrew Morton, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi, Peter Zijlstra, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm

As an ad-hoc experiment:  can you replace the call to remap_pfn_range
with remap_pfn_range_notrack (and export it if you build i915 modular)
in remap_io_sg and see if that makes any difference?


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-17 12:37       ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-17 12:37 UTC (permalink / raw)
  To: Serge Belyshev
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Andrew Morton, Christoph Hellwig

As an ad-hoc experiment:  can you replace the call to remap_pfn_range
with remap_pfn_range_notrack (and export it if you build i915 modular)
in remap_io_sg and see if that makes any difference?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-17 12:37       ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2021-05-17 13:09         ` Serge Belyshev
  -1 siblings, 0 replies; 63+ messages in thread
From: Serge Belyshev @ 2021-05-17 13:09 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
	Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm

Christoph Hellwig <hch@lst.de> writes:

> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
> with remap_pfn_range_notrack (and export it if you build i915 modular)
> in remap_io_sg and see if that makes any difference?

That worked, thanks -- no artifacts seen.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-17 13:09         ` Serge Belyshev
  0 siblings, 0 replies; 63+ messages in thread
From: Serge Belyshev @ 2021-05-17 13:09 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Rodrigo Vivi, Andrew Morton

Christoph Hellwig <hch@lst.de> writes:

> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
> with remap_pfn_range_notrack (and export it if you build i915 modular)
> in remap_io_sg and see if that makes any difference?

That worked, thanks -- no artifacts seen.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-17 13:09         ` Serge Belyshev
  0 siblings, 0 replies; 63+ messages in thread
From: Serge Belyshev @ 2021-05-17 13:09 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Andrew Morton

Christoph Hellwig <hch@lst.de> writes:

> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
> with remap_pfn_range_notrack (and export it if you build i915 modular)
> in remap_io_sg and see if that makes any difference?

That worked, thanks -- no artifacts seen.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-17 13:09         ` Serge Belyshev
@ 2021-05-17 13:11           ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-17 13:11 UTC (permalink / raw)
  To: Serge Belyshev
  Cc: Christoph Hellwig, Andrew Morton, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi, Peter Zijlstra, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm

On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
> Christoph Hellwig <hch@lst.de> writes:
> 
> > As an ad-hoc experiment:  can you replace the call to remap_pfn_range
> > with remap_pfn_range_notrack (and export it if you build i915 modular)
> > in remap_io_sg and see if that makes any difference?
> 
> That worked, thanks -- no artifacts seen.

Looks like it is caused by the validation failure then.  Which means the
existing code is doing something wrong in its choice of the page
protection bit.  I really need help from the i915 maintainers here..


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-17 13:11           ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-17 13:11 UTC (permalink / raw)
  To: Serge Belyshev
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Andrew Morton, Christoph Hellwig

On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
> Christoph Hellwig <hch@lst.de> writes:
> 
> > As an ad-hoc experiment:  can you replace the call to remap_pfn_range
> > with remap_pfn_range_notrack (and export it if you build i915 modular)
> > in remap_io_sg and see if that makes any difference?
> 
> That worked, thanks -- no artifacts seen.

Looks like it is caused by the validation failure then.  Which means the
existing code is doing something wrong in its choice of the page
protection bit.  I really need help from the i915 maintainers here..
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-17 13:11           ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2021-05-17 17:06             ` Matthew Auld
  -1 siblings, 0 replies; 63+ messages in thread
From: Matthew Auld @ 2021-05-17 17:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, Chris Wilson, linux-mm, ML dri-devel,
	Andrew Morton

On Mon, 17 May 2021 at 14:11, Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> >
> > > As an ad-hoc experiment:  can you replace the call to remap_pfn_range
> > > with remap_pfn_range_notrack (and export it if you build i915 modular)
> > > in remap_io_sg and see if that makes any difference?
> >
> > That worked, thanks -- no artifacts seen.
>
> Looks like it is caused by the validation failure then.  Which means the
> existing code is doing something wrong in its choice of the page
> protection bit.  I really need help from the i915 maintainers here..

AFAIK there are two users of remap_io_sg, the first is our shmem
objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
mmap modes for userspace. The other user is device local-memory
objects(VRAM), and for this one we have an actual io_mapping which is
allocated as WC, and IIRC this should only be mapped as WC for the
mmap mode, but normal userspace can't hit this path yet.

What do we need to do here? It sounds like shmem backed objects are
allocated as WB for the pages underneath, but i915 allows mapping them
as UC/WC which trips up this track_pfn thing?

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-17 17:06             ` Matthew Auld
  0 siblings, 0 replies; 63+ messages in thread
From: Matthew Auld @ 2021-05-17 17:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, ML dri-devel, Chris Wilson, linux-mm,
	Andrew Morton

On Mon, 17 May 2021 at 14:11, Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> >
> > > As an ad-hoc experiment:  can you replace the call to remap_pfn_range
> > > with remap_pfn_range_notrack (and export it if you build i915 modular)
> > > in remap_io_sg and see if that makes any difference?
> >
> > That worked, thanks -- no artifacts seen.
>
> Looks like it is caused by the validation failure then.  Which means the
> existing code is doing something wrong in its choice of the page
> protection bit.  I really need help from the i915 maintainers here..

AFAIK there are two users of remap_io_sg, the first is our shmem
objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
mmap modes for userspace. The other user is device local-memory
objects(VRAM), and for this one we have an actual io_mapping which is
allocated as WC, and IIRC this should only be mapped as WC for the
mmap mode, but normal userspace can't hit this path yet.

What do we need to do here? It sounds like shmem backed objects are
allocated as WB for the pages underneath, but i915 allows mapping them
as UC/WC which trips up this track_pfn thing?

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-17 17:06             ` Matthew Auld
  0 siblings, 0 replies; 63+ messages in thread
From: Matthew Auld @ 2021-05-17 17:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, ML dri-devel, Chris Wilson, linux-mm,
	Andrew Morton

On Mon, 17 May 2021 at 14:11, Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> >
> > > As an ad-hoc experiment:  can you replace the call to remap_pfn_range
> > > with remap_pfn_range_notrack (and export it if you build i915 modular)
> > > in remap_io_sg and see if that makes any difference?
> >
> > That worked, thanks -- no artifacts seen.
>
> Looks like it is caused by the validation failure then.  Which means the
> existing code is doing something wrong in its choice of the page
> protection bit.  I really need help from the i915 maintainers here..

AFAIK there are two users of remap_io_sg, the first is our shmem
objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
mmap modes for userspace. The other user is device local-memory
objects(VRAM), and for this one we have an actual io_mapping which is
allocated as WC, and IIRC this should only be mapped as WC for the
mmap mode, but normal userspace can't hit this path yet.

What do we need to do here? It sounds like shmem backed objects are
allocated as WB for the pages underneath, but i915 allows mapping them
as UC/WC which trips up this track_pfn thing?

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-17 13:11           ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2021-05-17 21:46             ` Thomas Hellström
  -1 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-17 21:46 UTC (permalink / raw)
  To: Christoph Hellwig, Serge Belyshev
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Andrew Morton


On 5/17/21 3:11 PM, Christoph Hellwig wrote:
> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
>> Christoph Hellwig <hch@lst.de> writes:
>>
>>> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
>>> with remap_pfn_range_notrack (and export it if you build i915 modular)
>>> in remap_io_sg and see if that makes any difference?
>> That worked, thanks -- no artifacts seen.
> Looks like it is caused by the validation failure then.  Which means the
> existing code is doing something wrong in its choice of the page
> protection bit.  I really need help from the i915 maintainers here..

Hmm,

Apart from the caching aliasing Mattew brought up, doesn't the 
remap_pfn_range_xxx() family require the mmap_sem held in write mode 
since it modifies the vma structure? remap_io_sg() is called from the 
fault handler with the mmap_sem held in read mode only.

/Thomas

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-17 21:46             ` Thomas Hellström
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-17 21:46 UTC (permalink / raw)
  To: Christoph Hellwig, Serge Belyshev
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm, Andrew Morton


On 5/17/21 3:11 PM, Christoph Hellwig wrote:
> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
>> Christoph Hellwig <hch@lst.de> writes:
>>
>>> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
>>> with remap_pfn_range_notrack (and export it if you build i915 modular)
>>> in remap_io_sg and see if that makes any difference?
>> That worked, thanks -- no artifacts seen.
> Looks like it is caused by the validation failure then.  Which means the
> existing code is doing something wrong in its choice of the page
> protection bit.  I really need help from the i915 maintainers here..

Hmm,

Apart from the caching aliasing Mattew brought up, doesn't the 
remap_pfn_range_xxx() family require the mmap_sem held in write mode 
since it modifies the vma structure? remap_io_sg() is called from the 
fault handler with the mmap_sem held in read mode only.

/Thomas

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-17 21:46             ` Thomas Hellström
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-17 21:46 UTC (permalink / raw)
  To: Christoph Hellwig, Serge Belyshev
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm, Andrew Morton


On 5/17/21 3:11 PM, Christoph Hellwig wrote:
> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
>> Christoph Hellwig <hch@lst.de> writes:
>>
>>> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
>>> with remap_pfn_range_notrack (and export it if you build i915 modular)
>>> in remap_io_sg and see if that makes any difference?
>> That worked, thanks -- no artifacts seen.
> Looks like it is caused by the validation failure then.  Which means the
> existing code is doing something wrong in its choice of the page
> protection bit.  I really need help from the i915 maintainers here..

Hmm,

Apart from the caching aliasing Mattew brought up, doesn't the 
remap_pfn_range_xxx() family require the mmap_sem held in write mode 
since it modifies the vma structure? remap_io_sg() is called from the 
fault handler with the mmap_sem held in read mode only.

/Thomas

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-17 21:46             ` Thomas Hellström
  (?)
@ 2021-05-18  6:46               ` Thomas Hellström
  -1 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-18  6:46 UTC (permalink / raw)
  To: Christoph Hellwig, Serge Belyshev
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, Chris Wilson, linux-mm,
	dri-devel, Andrew Morton


On 5/17/21 11:46 PM, Thomas Hellström wrote:
>
> On 5/17/21 3:11 PM, Christoph Hellwig wrote:
>> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
>>> Christoph Hellwig <hch@lst.de> writes:
>>>
>>>> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
>>>> with remap_pfn_range_notrack (and export it if you build i915 modular)
>>>> in remap_io_sg and see if that makes any difference?
>>> That worked, thanks -- no artifacts seen.
>> Looks like it is caused by the validation failure then.  Which means the
>> existing code is doing something wrong in its choice of the page
>> protection bit.  I really need help from the i915 maintainers here..
>
> Hmm,
>
> Apart from the caching aliasing Mattew brought up, doesn't the 
> remap_pfn_range_xxx() family require the mmap_sem held in write mode 
> since it modifies the vma structure? remap_io_sg() is called from the 
> fault handler with the mmap_sem held in read mode only.
>
> /Thomas

And worse, if we prefault a user-space buffer object map using 
remap_io_sg() and then zap some ptes using madvise(), the next time 
those ptes are accessed, we'd trigger a new call to remap_io_sg() which 
would now find already populated ptes. While the old code looks to just 
silently overwrite those, it looks like the new code would BUG in 
remap_pte_range()?

/Thomas




>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18  6:46               ` Thomas Hellström
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-18  6:46 UTC (permalink / raw)
  To: Christoph Hellwig, Serge Belyshev
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm, Andrew Morton


On 5/17/21 11:46 PM, Thomas Hellström wrote:
>
> On 5/17/21 3:11 PM, Christoph Hellwig wrote:
>> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
>>> Christoph Hellwig <hch@lst.de> writes:
>>>
>>>> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
>>>> with remap_pfn_range_notrack (and export it if you build i915 modular)
>>>> in remap_io_sg and see if that makes any difference?
>>> That worked, thanks -- no artifacts seen.
>> Looks like it is caused by the validation failure then.  Which means the
>> existing code is doing something wrong in its choice of the page
>> protection bit.  I really need help from the i915 maintainers here..
>
> Hmm,
>
> Apart from the caching aliasing Mattew brought up, doesn't the 
> remap_pfn_range_xxx() family require the mmap_sem held in write mode 
> since it modifies the vma structure? remap_io_sg() is called from the 
> fault handler with the mmap_sem held in read mode only.
>
> /Thomas

And worse, if we prefault a user-space buffer object map using 
remap_io_sg() and then zap some ptes using madvise(), the next time 
those ptes are accessed, we'd trigger a new call to remap_io_sg() which 
would now find already populated ptes. While the old code looks to just 
silently overwrite those, it looks like the new code would BUG in 
remap_pte_range()?

/Thomas




>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18  6:46               ` Thomas Hellström
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-18  6:46 UTC (permalink / raw)
  To: Christoph Hellwig, Serge Belyshev
  Cc: Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm, Andrew Morton


On 5/17/21 11:46 PM, Thomas Hellström wrote:
>
> On 5/17/21 3:11 PM, Christoph Hellwig wrote:
>> On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
>>> Christoph Hellwig <hch@lst.de> writes:
>>>
>>>> As an ad-hoc experiment:  can you replace the call to remap_pfn_range
>>>> with remap_pfn_range_notrack (and export it if you build i915 modular)
>>>> in remap_io_sg and see if that makes any difference?
>>> That worked, thanks -- no artifacts seen.
>> Looks like it is caused by the validation failure then.  Which means the
>> existing code is doing something wrong in its choice of the page
>> protection bit.  I really need help from the i915 maintainers here..
>
> Hmm,
>
> Apart from the caching aliasing Mattew brought up, doesn't the 
> remap_pfn_range_xxx() family require the mmap_sem held in write mode 
> since it modifies the vma structure? remap_io_sg() is called from the 
> fault handler with the mmap_sem held in read mode only.
>
> /Thomas

And worse, if we prefault a user-space buffer object map using 
remap_io_sg() and then zap some ptes using madvise(), the next time 
those ptes are accessed, we'd trigger a new call to remap_io_sg() which 
would now find already populated ptes. While the old code looks to just 
silently overwrite those, it looks like the new code would BUG in 
remap_pte_range()?

/Thomas




>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-17 17:06             ` Matthew Auld
@ 2021-05-18 13:21               ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-18 13:21 UTC (permalink / raw)
  To: Matthew Auld
  Cc: Christoph Hellwig, Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, Chris Wilson, linux-mm, ML dri-devel,
	Andrew Morton

On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > Looks like it is caused by the validation failure then.  Which means the
> > existing code is doing something wrong in its choice of the page
> > protection bit.  I really need help from the i915 maintainers here..
> 
> AFAIK there are two users of remap_io_sg, the first is our shmem
> objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
> mmap modes for userspace. The other user is device local-memory
> objects(VRAM), and for this one we have an actual io_mapping which is
> allocated as WC, and IIRC this should only be mapped as WC for the
> mmap mode, but normal userspace can't hit this path yet.

The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
Is that device local?

> What do we need to do here? It sounds like shmem backed objects are
> allocated as WB for the pages underneath, but i915 allows mapping them
> as UC/WC which trips up this track_pfn thing?

To me the warnings looks like system memory is mapped with the wrong
permissions, yes.  If you want to map it as UC/WC the right set_memory_*
needs to be used on the kernel mapping as well to ensure that the
attributes don't conflict.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18 13:21               ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-18 13:21 UTC (permalink / raw)
  To: Matthew Auld
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, ML dri-devel, Chris Wilson, linux-mm,
	Andrew Morton, Christoph Hellwig

On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > Looks like it is caused by the validation failure then.  Which means the
> > existing code is doing something wrong in its choice of the page
> > protection bit.  I really need help from the i915 maintainers here..
> 
> AFAIK there are two users of remap_io_sg, the first is our shmem
> objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
> mmap modes for userspace. The other user is device local-memory
> objects(VRAM), and for this one we have an actual io_mapping which is
> allocated as WC, and IIRC this should only be mapped as WC for the
> mmap mode, but normal userspace can't hit this path yet.

The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
Is that device local?

> What do we need to do here? It sounds like shmem backed objects are
> allocated as WB for the pages underneath, but i915 allows mapping them
> as UC/WC which trips up this track_pfn thing?

To me the warnings looks like system memory is mapped with the wrong
permissions, yes.  If you want to map it as UC/WC the right set_memory_*
needs to be used on the kernel mapping as well to ensure that the
attributes don't conflict.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-17 21:46             ` Thomas Hellström
@ 2021-05-18 13:23               ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-18 13:23 UTC (permalink / raw)
  To: Thomas Hellström
  Cc: Christoph Hellwig, Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	intel-gfx, Chris Wilson, linux-mm, dri-devel, Andrew Morton

On Mon, May 17, 2021 at 11:46:35PM +0200, Thomas Hellström wrote:
> Apart from the caching aliasing Mattew brought up, doesn't the 
> remap_pfn_range_xxx() family require the mmap_sem held in write mode since 
> it modifies the vma structure? remap_io_sg() is called from the fault 
> handler with the mmap_sem held in read mode only.

Only for vma->vm_flags, and remap_sg already asserts all the interesting
flags are set, although it does not assert VM_IO.

We could move the assignment out of remap_pfn_range_notrack and
into remap_pfn_range and just assert that the proper flags are set,
though.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18 13:23               ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-18 13:23 UTC (permalink / raw)
  To: Thomas Hellström
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm, Andrew Morton,
	Christoph Hellwig

On Mon, May 17, 2021 at 11:46:35PM +0200, Thomas Hellström wrote:
> Apart from the caching aliasing Mattew brought up, doesn't the 
> remap_pfn_range_xxx() family require the mmap_sem held in write mode since 
> it modifies the vma structure? remap_io_sg() is called from the fault 
> handler with the mmap_sem held in read mode only.

Only for vma->vm_flags, and remap_sg already asserts all the interesting
flags are set, although it does not assert VM_IO.

We could move the assignment out of remap_pfn_range_notrack and
into remap_pfn_range and just assert that the proper flags are set,
though.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-18  6:46               ` Thomas Hellström
@ 2021-05-18 13:24                 ` Christoph Hellwig
  -1 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-18 13:24 UTC (permalink / raw)
  To: Thomas Hellström
  Cc: Christoph Hellwig, Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	intel-gfx, Chris Wilson, linux-mm, dri-devel, Andrew Morton

On Tue, May 18, 2021 at 08:46:44AM +0200, Thomas Hellström wrote:
> And worse, if we prefault a user-space buffer object map using 
> remap_io_sg() and then zap some ptes using madvise(), the next time those 
> ptes are accessed, we'd trigger a new call to remap_io_sg() which would now 
> find already populated ptes. While the old code looks to just silently 
> overwrite those, it looks like the new code would BUG in remap_pte_range()?

How can you zap the PTEs using madvise?


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18 13:24                 ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-05-18 13:24 UTC (permalink / raw)
  To: Thomas Hellström
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm, Andrew Morton,
	Christoph Hellwig

On Tue, May 18, 2021 at 08:46:44AM +0200, Thomas Hellström wrote:
> And worse, if we prefault a user-space buffer object map using 
> remap_io_sg() and then zap some ptes using madvise(), the next time those 
> ptes are accessed, we'd trigger a new call to remap_io_sg() which would now 
> find already populated ptes. While the old code looks to just silently 
> overwrite those, it looks like the new code would BUG in remap_pte_range()?

How can you zap the PTEs using madvise?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-18 13:24                 ` Christoph Hellwig
  (?)
@ 2021-05-18 13:33                   ` Thomas Hellström
  -1 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-18 13:33 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter, intel-gfx,
	Chris Wilson, linux-mm, dri-devel, Andrew Morton


On 5/18/21 3:24 PM, Christoph Hellwig wrote:
> On Tue, May 18, 2021 at 08:46:44AM +0200, Thomas Hellström wrote:
>> And worse, if we prefault a user-space buffer object map using
>> remap_io_sg() and then zap some ptes using madvise(), the next time those
>> ptes are accessed, we'd trigger a new call to remap_io_sg() which would now
>> find already populated ptes. While the old code looks to just silently
>> overwrite those, it looks like the new code would BUG in remap_pte_range()?
> How can you zap the PTEs using madvise?

Hmm, that's not possible with VM_PFNMAP. My bad. Should be OK then.

/Thomas




^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18 13:33                   ` Thomas Hellström
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-18 13:33 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm, Andrew Morton


On 5/18/21 3:24 PM, Christoph Hellwig wrote:
> On Tue, May 18, 2021 at 08:46:44AM +0200, Thomas Hellström wrote:
>> And worse, if we prefault a user-space buffer object map using
>> remap_io_sg() and then zap some ptes using madvise(), the next time those
>> ptes are accessed, we'd trigger a new call to remap_io_sg() which would now
>> find already populated ptes. While the old code looks to just silently
>> overwrite those, it looks like the new code would BUG in remap_pte_range()?
> How can you zap the PTEs using madvise?

Hmm, that's not possible with VM_PFNMAP. My bad. Should be OK then.

/Thomas



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18 13:33                   ` Thomas Hellström
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-18 13:33 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm, Andrew Morton


On 5/18/21 3:24 PM, Christoph Hellwig wrote:
> On Tue, May 18, 2021 at 08:46:44AM +0200, Thomas Hellström wrote:
>> And worse, if we prefault a user-space buffer object map using
>> remap_io_sg() and then zap some ptes using madvise(), the next time those
>> ptes are accessed, we'd trigger a new call to remap_io_sg() which would now
>> find already populated ptes. While the old code looks to just silently
>> overwrite those, it looks like the new code would BUG in remap_pte_range()?
> How can you zap the PTEs using madvise?

Hmm, that's not possible with VM_PFNMAP. My bad. Should be OK then.

/Thomas


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-18 13:21               ` Christoph Hellwig
  (?)
@ 2021-05-18 15:00                 ` Matthew Auld
  -1 siblings, 0 replies; 63+ messages in thread
From: Matthew Auld @ 2021-05-18 15:00 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, Chris Wilson, linux-mm, ML dri-devel,
	Andrew Morton, Joonas Lahtinen

On Tue, 18 May 2021 at 14:21, Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > > Looks like it is caused by the validation failure then.  Which means the
> > > existing code is doing something wrong in its choice of the page
> > > protection bit.  I really need help from the i915 maintainers here..
> >
> > AFAIK there are two users of remap_io_sg, the first is our shmem
> > objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
> > mmap modes for userspace. The other user is device local-memory
> > objects(VRAM), and for this one we have an actual io_mapping which is
> > allocated as WC, and IIRC this should only be mapped as WC for the
> > mmap mode, but normal userspace can't hit this path yet.
>
> The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
> Is that device local?

The vm_fault_cpu covers both device local and shmem objects.

>
> > What do we need to do here? It sounds like shmem backed objects are
> > allocated as WB for the pages underneath, but i915 allows mapping them
> > as UC/WC which trips up this track_pfn thing?
>
> To me the warnings looks like system memory is mapped with the wrong
> permissions, yes.  If you want to map it as UC/WC the right set_memory_*
> needs to be used on the kernel mapping as well to ensure that the
> attributes don't conflict.

AFAIK mmap_offset also supports multiple active mmap modes for a given
object, so set_memory_* should still work here?


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18 15:00                 ` Matthew Auld
  0 siblings, 0 replies; 63+ messages in thread
From: Matthew Auld @ 2021-05-18 15:00 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, ML dri-devel, Chris Wilson, linux-mm,
	Andrew Morton

On Tue, 18 May 2021 at 14:21, Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > > Looks like it is caused by the validation failure then.  Which means the
> > > existing code is doing something wrong in its choice of the page
> > > protection bit.  I really need help from the i915 maintainers here..
> >
> > AFAIK there are two users of remap_io_sg, the first is our shmem
> > objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
> > mmap modes for userspace. The other user is device local-memory
> > objects(VRAM), and for this one we have an actual io_mapping which is
> > allocated as WC, and IIRC this should only be mapped as WC for the
> > mmap mode, but normal userspace can't hit this path yet.
>
> The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
> Is that device local?

The vm_fault_cpu covers both device local and shmem objects.

>
> > What do we need to do here? It sounds like shmem backed objects are
> > allocated as WB for the pages underneath, but i915 allows mapping them
> > as UC/WC which trips up this track_pfn thing?
>
> To me the warnings looks like system memory is mapped with the wrong
> permissions, yes.  If you want to map it as UC/WC the right set_memory_*
> needs to be used on the kernel mapping as well to ensure that the
> attributes don't conflict.

AFAIK mmap_offset also supports multiple active mmap modes for a given
object, so set_memory_* should still work here?

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-18 15:00                 ` Matthew Auld
  0 siblings, 0 replies; 63+ messages in thread
From: Matthew Auld @ 2021-05-18 15:00 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, ML dri-devel, Chris Wilson, linux-mm,
	Andrew Morton

On Tue, 18 May 2021 at 14:21, Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > > Looks like it is caused by the validation failure then.  Which means the
> > > existing code is doing something wrong in its choice of the page
> > > protection bit.  I really need help from the i915 maintainers here..
> >
> > AFAIK there are two users of remap_io_sg, the first is our shmem
> > objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
> > mmap modes for userspace. The other user is device local-memory
> > objects(VRAM), and for this one we have an actual io_mapping which is
> > allocated as WC, and IIRC this should only be mapped as WC for the
> > mmap mode, but normal userspace can't hit this path yet.
>
> The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
> Is that device local?

The vm_fault_cpu covers both device local and shmem objects.

>
> > What do we need to do here? It sounds like shmem backed objects are
> > allocated as WB for the pages underneath, but i915 allows mapping them
> > as UC/WC which trips up this track_pfn thing?
>
> To me the warnings looks like system memory is mapped with the wrong
> permissions, yes.  If you want to map it as UC/WC the right set_memory_*
> needs to be used on the kernel mapping as well to ensure that the
> attributes don't conflict.

AFAIK mmap_offset also supports multiple active mmap modes for a given
object, so set_memory_* should still work here?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-18 15:00                 ` Matthew Auld
@ 2021-05-19  5:46                   ` Thomas Hellström (Intel)
  -1 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström (Intel) @ 2021-05-19  5:46 UTC (permalink / raw)
  To: Matthew Auld, Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, ML dri-devel, Chris Wilson, linux-mm,
	Andrew Morton


On 5/18/21 5:00 PM, Matthew Auld wrote:
> On Tue, 18 May 2021 at 14:21, Christoph Hellwig <hch@lst.de> wrote:
>> On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
>>>> Looks like it is caused by the validation failure then.  Which means the
>>>> existing code is doing something wrong in its choice of the page
>>>> protection bit.  I really need help from the i915 maintainers here..
>>> AFAIK there are two users of remap_io_sg, the first is our shmem
>>> objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
>>> mmap modes for userspace. The other user is device local-memory
>>> objects(VRAM), and for this one we have an actual io_mapping which is
>>> allocated as WC, and IIRC this should only be mapped as WC for the
>>> mmap mode, but normal userspace can't hit this path yet.
>> The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
>> Is that device local?
> The vm_fault_cpu covers both device local and shmem objects.
>
>>> What do we need to do here? It sounds like shmem backed objects are
>>> allocated as WB for the pages underneath, but i915 allows mapping them
>>> as UC/WC which trips up this track_pfn thing?
>> To me the warnings looks like system memory is mapped with the wrong
>> permissions, yes.  If you want to map it as UC/WC the right set_memory_*
>> needs to be used on the kernel mapping as well to ensure that the
>> attributes don't conflict.
> AFAIK mmap_offset also supports multiple active mmap modes for a given
> object, so set_memory_* should still work here?

No, that won't work because there are active maps with conflicting 
caching attributes. I think the history here is that that was assumed to 
be OK for integrated graphics that ran only on Intel processors that 
promise to never write back unmodified cache lines resulting from 
prefetching, like some AMD processors did way back at least.

These conflicting mappings can obviously not be supported for discrete 
graphics, but for integrated they are part of the uAPI.

/Thomas





> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-19  5:46                   ` Thomas Hellström (Intel)
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström (Intel) @ 2021-05-19  5:46 UTC (permalink / raw)
  To: Matthew Auld, Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter,
	Intel Graphics Development, ML dri-devel, Chris Wilson, linux-mm,
	Andrew Morton


On 5/18/21 5:00 PM, Matthew Auld wrote:
> On Tue, 18 May 2021 at 14:21, Christoph Hellwig <hch@lst.de> wrote:
>> On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
>>>> Looks like it is caused by the validation failure then.  Which means the
>>>> existing code is doing something wrong in its choice of the page
>>>> protection bit.  I really need help from the i915 maintainers here..
>>> AFAIK there are two users of remap_io_sg, the first is our shmem
>>> objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
>>> mmap modes for userspace. The other user is device local-memory
>>> objects(VRAM), and for this one we have an actual io_mapping which is
>>> allocated as WC, and IIRC this should only be mapped as WC for the
>>> mmap mode, but normal userspace can't hit this path yet.
>> The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
>> Is that device local?
> The vm_fault_cpu covers both device local and shmem objects.
>
>>> What do we need to do here? It sounds like shmem backed objects are
>>> allocated as WB for the pages underneath, but i915 allows mapping them
>>> as UC/WC which trips up this track_pfn thing?
>> To me the warnings looks like system memory is mapped with the wrong
>> permissions, yes.  If you want to map it as UC/WC the right set_memory_*
>> needs to be used on the kernel mapping as well to ensure that the
>> attributes don't conflict.
> AFAIK mmap_offset also supports multiple active mmap modes for a given
> object, so set_memory_* should still work here?

No, that won't work because there are active maps with conflicting 
caching attributes. I think the history here is that that was assumed to 
be OK for integrated graphics that ran only on Intel processors that 
promise to never write back unmodified cache lines resulting from 
prefetching, like some AMD processors did way back at least.

These conflicting mappings can obviously not be supported for discrete 
graphics, but for integrated they are part of the uAPI.

/Thomas





> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
  2021-05-18 13:23               ` Christoph Hellwig
  (?)
@ 2021-05-19  5:51                 ` Thomas Hellström
  -1 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-19  5:51 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter, intel-gfx,
	Chris Wilson, linux-mm, dri-devel, Andrew Morton


On 5/18/21 3:23 PM, Christoph Hellwig wrote:
> On Mon, May 17, 2021 at 11:46:35PM +0200, Thomas Hellström wrote:
>> Apart from the caching aliasing Mattew brought up, doesn't the
>> remap_pfn_range_xxx() family require the mmap_sem held in write mode since
>> it modifies the vma structure? remap_io_sg() is called from the fault
>> handler with the mmap_sem held in read mode only.
> Only for vma->vm_flags, and remap_sg already asserts all the interesting
> flags are set, although it does not assert VM_IO.
>
> We could move the assignment out of remap_pfn_range_notrack and
> into remap_pfn_range and just assert that the proper flags are set,
> though.

That to me sounds like a way forward. It sound like in general a gpu 
prefaulting helper that in the long run also supports faulting huge ptes 
is desired also by TTM. Although it looks like that BUG_ON() I pointed 
out was hit anyway....

/Thomas




^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-19  5:51                 ` Thomas Hellström
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-19  5:51 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm, Andrew Morton


On 5/18/21 3:23 PM, Christoph Hellwig wrote:
> On Mon, May 17, 2021 at 11:46:35PM +0200, Thomas Hellström wrote:
>> Apart from the caching aliasing Mattew brought up, doesn't the
>> remap_pfn_range_xxx() family require the mmap_sem held in write mode since
>> it modifies the vma structure? remap_io_sg() is called from the fault
>> handler with the mmap_sem held in read mode only.
> Only for vma->vm_flags, and remap_sg already asserts all the interesting
> flags are set, although it does not assert VM_IO.
>
> We could move the assignment out of remap_pfn_range_notrack and
> into remap_pfn_range and just assert that the proper flags are set,
> though.

That to me sounds like a way forward. It sound like in general a gpu 
prefaulting helper that in the long run also supports faulting huge ptes 
is desired also by TTM. Although it looks like that BUG_ON() I pointed 
out was hit anyway....

/Thomas



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot
@ 2021-05-19  5:51                 ` Thomas Hellström
  0 siblings, 0 replies; 63+ messages in thread
From: Thomas Hellström @ 2021-05-19  5:51 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Serge Belyshev, Peter Zijlstra, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm, Andrew Morton


On 5/18/21 3:23 PM, Christoph Hellwig wrote:
> On Mon, May 17, 2021 at 11:46:35PM +0200, Thomas Hellström wrote:
>> Apart from the caching aliasing Mattew brought up, doesn't the
>> remap_pfn_range_xxx() family require the mmap_sem held in write mode since
>> it modifies the vma structure? remap_io_sg() is called from the fault
>> handler with the mmap_sem held in read mode only.
> Only for vma->vm_flags, and remap_sg already asserts all the interesting
> flags are set, although it does not assert VM_IO.
>
> We could move the assignment out of remap_pfn_range_notrack and
> into remap_pfn_range and just assert that the proper flags are set,
> though.

That to me sounds like a way forward. It sound like in general a gpu 
prefaulting helper that in the long run also supports faulting huge ptes 
is desired also by TTM. Although it looks like that BUG_ON() I pointed 
out was hit anyway....

/Thomas


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 2/4] mm: add a io_mapping_map_user helper
  2021-03-26  5:55   ` [Intel-gfx] " Christoph Hellwig
  (?)
@ 2021-10-20 15:40   ` Lucas De Marchi
  2021-10-20 19:37     ` Peter Zijlstra
  -1 siblings, 1 reply; 63+ messages in thread
From: Lucas De Marchi @ 2021-10-20 15:40 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
	Peter Zijlstra, Daniel Vetter, intel-gfx, dri-devel,
	Chris Wilson, linux-mm, matthew.auld

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
>


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 2/4] mm: add a io_mapping_map_user helper
  2021-10-20 15:40   ` Lucas De Marchi
@ 2021-10-20 19:37     ` Peter Zijlstra
  2021-10-21  6:18       ` Christoph Hellwig
  0 siblings, 1 reply; 63+ messages in thread
From: Peter Zijlstra @ 2021-10-20 19:37 UTC (permalink / raw)
  To: Lucas De Marchi
  Cc: Christoph Hellwig, Andrew Morton, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi, Daniel Vetter, intel-gfx, dri-devel, Chris Wilson,
	linux-mm, matthew.auld

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.


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [Intel-gfx] [PATCH 2/4] mm: add a io_mapping_map_user helper
  2021-10-20 19:37     ` Peter Zijlstra
@ 2021-10-21  6:18       ` Christoph Hellwig
  0 siblings, 0 replies; 63+ messages in thread
From: Christoph Hellwig @ 2021-10-21  6:18 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Lucas De Marchi, Christoph Hellwig, Andrew Morton, Jani Nikula,
	Joonas Lahtinen, Rodrigo Vivi, Daniel Vetter, intel-gfx,
	dri-devel, Chris Wilson, linux-mm, matthew.auld

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.


^ permalink raw reply	[flat|nested] 63+ messages in thread

end of thread, other threads:[~2021-10-21  6:18 UTC | newest]

Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-26  5:55 add remap_pfn_range_notrack instead of reinventing it in i915 v2 Christoph Hellwig
2021-03-26  5:55 ` [Intel-gfx] " Christoph Hellwig
2021-03-26  5:55 ` [PATCH 1/4] mm: add remap_pfn_range_notrack Christoph Hellwig
2021-03-26  5:55   ` [Intel-gfx] " Christoph Hellwig
2021-03-26  5:55 ` [PATCH 2/4] mm: add a io_mapping_map_user helper Christoph Hellwig
2021-03-26  5:55   ` [Intel-gfx] " Christoph Hellwig
2021-10-20 15:40   ` Lucas De Marchi
2021-10-20 19:37     ` Peter Zijlstra
2021-10-21  6:18       ` Christoph Hellwig
2021-03-26  5:55 ` [PATCH 3/4] i915: use io_mapping_map_user Christoph Hellwig
2021-03-26  5:55   ` [Intel-gfx] " Christoph Hellwig
2021-03-26  5:55 ` [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot Christoph Hellwig
2021-03-26  5:55   ` [Intel-gfx] " Christoph Hellwig
2021-05-08 19:33   ` youling257
2021-05-08 19:33     ` youling257
2021-05-08 19:33     ` youling257
2021-05-10  8:58     ` Christoph Hellwig
2021-05-10  8:58       ` Christoph Hellwig
2021-05-16 16:06   ` Serge Belyshev
2021-05-16 16:06     ` [Intel-gfx] " Serge Belyshev
2021-05-16 16:06     ` Serge Belyshev
2021-05-17 12:37     ` Christoph Hellwig
2021-05-17 12:37       ` [Intel-gfx] " Christoph Hellwig
2021-05-17 13:09       ` Serge Belyshev
2021-05-17 13:09         ` [Intel-gfx] " Serge Belyshev
2021-05-17 13:09         ` Serge Belyshev
2021-05-17 13:11         ` Christoph Hellwig
2021-05-17 13:11           ` [Intel-gfx] " Christoph Hellwig
2021-05-17 17:06           ` Matthew Auld
2021-05-17 17:06             ` Matthew Auld
2021-05-17 17:06             ` Matthew Auld
2021-05-18 13:21             ` Christoph Hellwig
2021-05-18 13:21               ` Christoph Hellwig
2021-05-18 15:00               ` Matthew Auld
2021-05-18 15:00                 ` Matthew Auld
2021-05-18 15:00                 ` Matthew Auld
2021-05-19  5:46                 ` Thomas Hellström (Intel)
2021-05-19  5:46                   ` Thomas Hellström (Intel)
2021-05-17 21:46           ` Thomas Hellström
2021-05-17 21:46             ` Thomas Hellström
2021-05-17 21:46             ` Thomas Hellström
2021-05-18  6:46             ` Thomas Hellström
2021-05-18  6:46               ` Thomas Hellström
2021-05-18  6:46               ` Thomas Hellström
2021-05-18 13:24               ` Christoph Hellwig
2021-05-18 13:24                 ` Christoph Hellwig
2021-05-18 13:33                 ` Thomas Hellström
2021-05-18 13:33                   ` Thomas Hellström
2021-05-18 13:33                   ` Thomas Hellström
2021-05-18 13:23             ` Christoph Hellwig
2021-05-18 13:23               ` Christoph Hellwig
2021-05-19  5:51               ` Thomas Hellström
2021-05-19  5:51                 ` Thomas Hellström
2021-05-19  5:51                 ` Thomas Hellström
2021-03-26  7:28 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] mm: add remap_pfn_range_notrack Patchwork
2021-03-26  7:31 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-03-26  7:34 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-03-26  7:59 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-04-08 10:36 ` add remap_pfn_range_notrack instead of reinventing it in i915 v2 Daniel Vetter
2021-04-08 10:36   ` [Intel-gfx] " Daniel Vetter
2021-04-08 10:36   ` Daniel Vetter
2021-04-08 11:28   ` Christoph Hellwig
2021-04-08 11:28     ` [Intel-gfx] " Christoph Hellwig

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.