All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:07 ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:07 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

Sometimes we need to create a struct file to wrap a drm_device, as it
the user were to have opened /dev/dri/card0 but to do so anonymously
(i.e. for internal use). Provide a utility method to create a struct
file with the drm_device->driver.fops, that wrap the drm_device.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/drm_file.c | 39 ++++++++++++++++++++++++++++++++++++++
 include/drm/drm_file.h     |  3 +++
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ea34bc991858..cc55c0cd5826 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -31,7 +31,9 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include <linux/anon_inodes.h>
 #include <linux/dma-fence.h>
+#include <linux/file.h>
 #include <linux/module.h>
 #include <linux/pci.h>
 #include <linux/poll.h>
@@ -754,3 +756,40 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
 	spin_unlock_irqrestore(&dev->event_lock, irqflags);
 }
 EXPORT_SYMBOL(drm_send_event);
+
+/**
+ * anon_drm_getfile - Create a new struct file for the drm device
+ * @minor: drm minor to wrap (e.g. drm_device->primary)
+ * @flags: file creation mode (O_RDWR etc)
+ *
+ * This create a new struct file that wraps a DRM file context around a
+ * DRM minor. This mimicks userspace opening e.g. /dev/dri/card0, but without
+ * invoking userspace. The struct file may be operated on using its f_op
+ * (the drm_device.driver.fops) to mimick userspace operations, or be supplied
+ * to userspace facing functions as an internal/anonymous client.
+ *
+ * RETURNS:
+ * Pointer to newly created struct file, ERR_PTR on failure.
+ */
+struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags)
+{
+	struct drm_device *dev = minor->dev;
+	struct drm_file *priv;
+	struct file *file;
+
+	priv = drm_file_alloc(minor);
+	if (IS_ERR(priv))
+		return ERR_CAST(priv);
+
+	file = anon_inode_getfile("drm", dev->driver->fops, priv, flags);
+	if (IS_ERR(file)) {
+		drm_file_free(priv);
+		return file;
+	}
+
+	drm_dev_get(dev);
+	priv->filp = file;
+
+	return file;
+}
+EXPORT_SYMBOL(anon_drm_getfile);
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 67af60bb527a..b963535964f7 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -42,6 +42,7 @@ struct dma_fence;
 struct drm_file;
 struct drm_device;
 struct device;
+struct file;
 
 /*
  * FIXME: Not sure we want to have drm_minor here in the end, but to avoid
@@ -387,4 +388,6 @@ void drm_event_cancel_free(struct drm_device *dev,
 void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e);
 void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
 
+struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags);
+
 #endif /* _DRM_FILE_H_ */
-- 
2.24.0

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

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

* [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:07 ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:07 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

Sometimes we need to create a struct file to wrap a drm_device, as it
the user were to have opened /dev/dri/card0 but to do so anonymously
(i.e. for internal use). Provide a utility method to create a struct
file with the drm_device->driver.fops, that wrap the drm_device.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/drm_file.c | 39 ++++++++++++++++++++++++++++++++++++++
 include/drm/drm_file.h     |  3 +++
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ea34bc991858..cc55c0cd5826 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -31,7 +31,9 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include <linux/anon_inodes.h>
 #include <linux/dma-fence.h>
+#include <linux/file.h>
 #include <linux/module.h>
 #include <linux/pci.h>
 #include <linux/poll.h>
@@ -754,3 +756,40 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
 	spin_unlock_irqrestore(&dev->event_lock, irqflags);
 }
 EXPORT_SYMBOL(drm_send_event);
+
+/**
+ * anon_drm_getfile - Create a new struct file for the drm device
+ * @minor: drm minor to wrap (e.g. drm_device->primary)
+ * @flags: file creation mode (O_RDWR etc)
+ *
+ * This create a new struct file that wraps a DRM file context around a
+ * DRM minor. This mimicks userspace opening e.g. /dev/dri/card0, but without
+ * invoking userspace. The struct file may be operated on using its f_op
+ * (the drm_device.driver.fops) to mimick userspace operations, or be supplied
+ * to userspace facing functions as an internal/anonymous client.
+ *
+ * RETURNS:
+ * Pointer to newly created struct file, ERR_PTR on failure.
+ */
+struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags)
+{
+	struct drm_device *dev = minor->dev;
+	struct drm_file *priv;
+	struct file *file;
+
+	priv = drm_file_alloc(minor);
+	if (IS_ERR(priv))
+		return ERR_CAST(priv);
+
+	file = anon_inode_getfile("drm", dev->driver->fops, priv, flags);
+	if (IS_ERR(file)) {
+		drm_file_free(priv);
+		return file;
+	}
+
+	drm_dev_get(dev);
+	priv->filp = file;
+
+	return file;
+}
+EXPORT_SYMBOL(anon_drm_getfile);
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 67af60bb527a..b963535964f7 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -42,6 +42,7 @@ struct dma_fence;
 struct drm_file;
 struct drm_device;
 struct device;
+struct file;
 
 /*
  * FIXME: Not sure we want to have drm_minor here in the end, but to avoid
@@ -387,4 +388,6 @@ void drm_event_cancel_free(struct drm_device *dev,
 void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e);
 void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
 
+struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags);
+
 #endif /* _DRM_FILE_H_ */
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:07 ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:07 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

Sometimes we need to create a struct file to wrap a drm_device, as it
the user were to have opened /dev/dri/card0 but to do so anonymously
(i.e. for internal use). Provide a utility method to create a struct
file with the drm_device->driver.fops, that wrap the drm_device.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/drm_file.c | 39 ++++++++++++++++++++++++++++++++++++++
 include/drm/drm_file.h     |  3 +++
 2 files changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ea34bc991858..cc55c0cd5826 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -31,7 +31,9 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include <linux/anon_inodes.h>
 #include <linux/dma-fence.h>
+#include <linux/file.h>
 #include <linux/module.h>
 #include <linux/pci.h>
 #include <linux/poll.h>
@@ -754,3 +756,40 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
 	spin_unlock_irqrestore(&dev->event_lock, irqflags);
 }
 EXPORT_SYMBOL(drm_send_event);
+
+/**
+ * anon_drm_getfile - Create a new struct file for the drm device
+ * @minor: drm minor to wrap (e.g. drm_device->primary)
+ * @flags: file creation mode (O_RDWR etc)
+ *
+ * This create a new struct file that wraps a DRM file context around a
+ * DRM minor. This mimicks userspace opening e.g. /dev/dri/card0, but without
+ * invoking userspace. The struct file may be operated on using its f_op
+ * (the drm_device.driver.fops) to mimick userspace operations, or be supplied
+ * to userspace facing functions as an internal/anonymous client.
+ *
+ * RETURNS:
+ * Pointer to newly created struct file, ERR_PTR on failure.
+ */
+struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags)
+{
+	struct drm_device *dev = minor->dev;
+	struct drm_file *priv;
+	struct file *file;
+
+	priv = drm_file_alloc(minor);
+	if (IS_ERR(priv))
+		return ERR_CAST(priv);
+
+	file = anon_inode_getfile("drm", dev->driver->fops, priv, flags);
+	if (IS_ERR(file)) {
+		drm_file_free(priv);
+		return file;
+	}
+
+	drm_dev_get(dev);
+	priv->filp = file;
+
+	return file;
+}
+EXPORT_SYMBOL(anon_drm_getfile);
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 67af60bb527a..b963535964f7 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -42,6 +42,7 @@ struct dma_fence;
 struct drm_file;
 struct drm_device;
 struct device;
+struct file;
 
 /*
  * FIXME: Not sure we want to have drm_minor here in the end, but to avoid
@@ -387,4 +388,6 @@ void drm_event_cancel_free(struct drm_device *dev,
 void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e);
 void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
 
+struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags);
+
 #endif /* _DRM_FILE_H_ */
-- 
2.24.0

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

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

* [PATCH 2/3] drm/i915/selftests: Wrap vm_mmap() around GEM objects
@ 2019-11-06 10:07   ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:07 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
---
 drivers/gpu/drm/i915/Makefile                 |  1 +
 .../drm/i915/gem/selftests/i915_gem_mman.c    | 97 +++++++++++++++++++
 drivers/gpu/drm/i915/selftests/igt_mmap.c     | 39 ++++++++
 drivers/gpu/drm/i915/selftests/igt_mmap.h     | 19 ++++
 4 files changed, 156 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/selftests/igt_mmap.c
 create mode 100644 drivers/gpu/drm/i915/selftests/igt_mmap.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 90dcf09f52cc..e0fd10c0cfb8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -259,6 +259,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
 	selftests/i915_selftest.o \
 	selftests/igt_flush_test.o \
 	selftests/igt_live_test.o \
+	selftests/igt_mmap.o \
 	selftests/igt_reset.o \
 	selftests/igt_spinner.o
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 29b2077b73d2..11a99d5d2ff8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -12,6 +12,7 @@
 #include "i915_selftest.h"
 #include "selftests/i915_random.h"
 #include "selftests/igt_flush_test.h"
+#include "selftests/igt_mmap.h"
 
 struct tile {
 	unsigned int width;
@@ -694,12 +695,108 @@ static int igt_mmap_offset_exhaustion(void *arg)
 	goto out;
 }
 
+#define expand32(x) (((x) << 0) | ((x) << 8) | ((x) << 16) | ((x) << 24))
+static int igt_mmap_gtt(void *arg)
+{
+	struct drm_i915_private *i915 = arg;
+	struct drm_i915_gem_object *obj;
+	struct vm_area_struct *area;
+	unsigned long addr;
+	void *vaddr;
+	int err, i;
+
+	obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+	if (IS_ERR(obj))
+		return PTR_ERR(obj);
+
+	vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+	if (IS_ERR(vaddr)) {
+		err = PTR_ERR(vaddr);
+		goto out;
+	}
+	memset(vaddr, POISON_INUSE, PAGE_SIZE);
+	i915_gem_object_flush_map(obj);
+	i915_gem_object_unpin_map(obj);
+
+	err = create_mmap_offset(obj);
+	if (err)
+		goto out;
+
+	addr = igt_mmap_node(i915, &obj->base.vma_node,
+			     0, PROT_WRITE, MAP_SHARED);
+	if (IS_ERR_VALUE(addr)) {
+		err = addr;
+		goto out;
+	}
+
+	pr_info("igt_mmap(obj:gtt) @ %lx\n", addr);
+
+	area = find_vma(current->mm, addr);
+	if (!area) {
+		pr_err("Did not create a vm_area_struct for the mmap\n");
+		err = -EINVAL;
+		goto out_unmap;
+	}
+
+	if (area->vm_private_data != obj) {
+		pr_err("vm_area_struct did not point back to our object!\n");
+		err = -EINVAL;
+		goto out_unmap;
+	}
+
+	for (i = 0; i < PAGE_SIZE / sizeof(u32); i++) {
+		u32 __user *ux = u64_to_user_ptr((u64)(addr + i * sizeof*(ux)));
+		u32 x;
+
+		if (get_user(x, ux)) {
+			pr_err("Unable to read from GTT mmap, offset:%zd\n",
+			       i * sizeof(x));
+			err = -EFAULT;
+			break;
+		}
+
+		if (x != expand32(POISON_INUSE)) {
+			pr_err("Read incorrect value from GTT mmap, offset:%zd, found:%x, expected:%x\n",
+			       i * sizeof(x), x, expand32(POISON_INUSE));
+			err = -EINVAL;
+			break;
+		}
+
+		x = expand32(POISON_FREE);
+		if (put_user(x, ux)) {
+			pr_err("Unable to write to GTT mmap, offset:%zd\n",
+			       i * sizeof(x));
+			err = -EFAULT;
+			break;
+		}
+	}
+
+out_unmap:
+	vm_munmap(addr, PAGE_SIZE);
+
+	vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
+	if (IS_ERR(vaddr)) {
+		err = PTR_ERR(vaddr);
+		goto out;
+	}
+	if (err == 0 && memchr_inv(vaddr, POISON_FREE, PAGE_SIZE)) {
+		pr_err("Write via GGTT mmap did not land in backing store\n");
+		err = -EINVAL;
+	}
+	i915_gem_object_unpin_map(obj);
+
+out:
+	i915_gem_object_put(obj);
+	return err;
+}
+
 int i915_gem_mman_live_selftests(struct drm_i915_private *i915)
 {
 	static const struct i915_subtest tests[] = {
 		SUBTEST(igt_partial_tiling),
 		SUBTEST(igt_smoke_tiling),
 		SUBTEST(igt_mmap_offset_exhaustion),
+		SUBTEST(igt_mmap_gtt),
 	};
 
 	return i915_subtests(tests, i915);
diff --git a/drivers/gpu/drm/i915/selftests/igt_mmap.c b/drivers/gpu/drm/i915/selftests/igt_mmap.c
new file mode 100644
index 000000000000..f5bc80e92573
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_mmap.c
@@ -0,0 +1,39 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include <drm/drm_file.h>
+
+#include "i915_drv.h"
+#include "igt_mmap.h"
+
+unsigned long igt_mmap_node(struct drm_i915_private *i915,
+			    struct drm_vma_offset_node *node,
+			    unsigned long addr,
+			    unsigned long prot,
+			    unsigned long flags)
+{
+	struct file *file;
+	int err;
+
+	/* Pretend to open("/dev/dri/card0") */
+	file = anon_drm_getfile(i915->drm.primary, O_RDWR);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
+
+	err = drm_vma_node_allow(node, file->private_data);
+	if (err) {
+		addr = err;
+		goto out_file;
+	}
+
+	addr = vm_mmap(file, addr, drm_vma_node_size(node) << PAGE_SHIFT,
+		       prot, flags, drm_vma_node_offset_addr(node));
+
+	drm_vma_node_revoke(node, file->private_data);
+out_file:
+	fput(file);
+	return addr;
+}
diff --git a/drivers/gpu/drm/i915/selftests/igt_mmap.h b/drivers/gpu/drm/i915/selftests/igt_mmap.h
new file mode 100644
index 000000000000..6e716cb59d7e
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_mmap.h
@@ -0,0 +1,19 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef IGT_MMAP_H
+#define IGT_MMAP_H
+
+struct drm_i915_private;
+struct drm_vma_offset_node;
+
+unsigned long igt_mmap_node(struct drm_i915_private *i915,
+			    struct drm_vma_offset_node *node,
+			    unsigned long addr,
+			    unsigned long prot,
+			    unsigned long flags);
+
+#endif /* IGT_MMAP_H */
-- 
2.24.0

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

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

* [PATCH 2/3] drm/i915/selftests: Wrap vm_mmap() around GEM objects
@ 2019-11-06 10:07   ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:07 UTC (permalink / raw)
  To: dri-devel; +Cc: Abdiel Janulgue, intel-gfx

Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
---
 drivers/gpu/drm/i915/Makefile                 |  1 +
 .../drm/i915/gem/selftests/i915_gem_mman.c    | 97 +++++++++++++++++++
 drivers/gpu/drm/i915/selftests/igt_mmap.c     | 39 ++++++++
 drivers/gpu/drm/i915/selftests/igt_mmap.h     | 19 ++++
 4 files changed, 156 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/selftests/igt_mmap.c
 create mode 100644 drivers/gpu/drm/i915/selftests/igt_mmap.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 90dcf09f52cc..e0fd10c0cfb8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -259,6 +259,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
 	selftests/i915_selftest.o \
 	selftests/igt_flush_test.o \
 	selftests/igt_live_test.o \
+	selftests/igt_mmap.o \
 	selftests/igt_reset.o \
 	selftests/igt_spinner.o
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 29b2077b73d2..11a99d5d2ff8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -12,6 +12,7 @@
 #include "i915_selftest.h"
 #include "selftests/i915_random.h"
 #include "selftests/igt_flush_test.h"
+#include "selftests/igt_mmap.h"
 
 struct tile {
 	unsigned int width;
@@ -694,12 +695,108 @@ static int igt_mmap_offset_exhaustion(void *arg)
 	goto out;
 }
 
+#define expand32(x) (((x) << 0) | ((x) << 8) | ((x) << 16) | ((x) << 24))
+static int igt_mmap_gtt(void *arg)
+{
+	struct drm_i915_private *i915 = arg;
+	struct drm_i915_gem_object *obj;
+	struct vm_area_struct *area;
+	unsigned long addr;
+	void *vaddr;
+	int err, i;
+
+	obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+	if (IS_ERR(obj))
+		return PTR_ERR(obj);
+
+	vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+	if (IS_ERR(vaddr)) {
+		err = PTR_ERR(vaddr);
+		goto out;
+	}
+	memset(vaddr, POISON_INUSE, PAGE_SIZE);
+	i915_gem_object_flush_map(obj);
+	i915_gem_object_unpin_map(obj);
+
+	err = create_mmap_offset(obj);
+	if (err)
+		goto out;
+
+	addr = igt_mmap_node(i915, &obj->base.vma_node,
+			     0, PROT_WRITE, MAP_SHARED);
+	if (IS_ERR_VALUE(addr)) {
+		err = addr;
+		goto out;
+	}
+
+	pr_info("igt_mmap(obj:gtt) @ %lx\n", addr);
+
+	area = find_vma(current->mm, addr);
+	if (!area) {
+		pr_err("Did not create a vm_area_struct for the mmap\n");
+		err = -EINVAL;
+		goto out_unmap;
+	}
+
+	if (area->vm_private_data != obj) {
+		pr_err("vm_area_struct did not point back to our object!\n");
+		err = -EINVAL;
+		goto out_unmap;
+	}
+
+	for (i = 0; i < PAGE_SIZE / sizeof(u32); i++) {
+		u32 __user *ux = u64_to_user_ptr((u64)(addr + i * sizeof*(ux)));
+		u32 x;
+
+		if (get_user(x, ux)) {
+			pr_err("Unable to read from GTT mmap, offset:%zd\n",
+			       i * sizeof(x));
+			err = -EFAULT;
+			break;
+		}
+
+		if (x != expand32(POISON_INUSE)) {
+			pr_err("Read incorrect value from GTT mmap, offset:%zd, found:%x, expected:%x\n",
+			       i * sizeof(x), x, expand32(POISON_INUSE));
+			err = -EINVAL;
+			break;
+		}
+
+		x = expand32(POISON_FREE);
+		if (put_user(x, ux)) {
+			pr_err("Unable to write to GTT mmap, offset:%zd\n",
+			       i * sizeof(x));
+			err = -EFAULT;
+			break;
+		}
+	}
+
+out_unmap:
+	vm_munmap(addr, PAGE_SIZE);
+
+	vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
+	if (IS_ERR(vaddr)) {
+		err = PTR_ERR(vaddr);
+		goto out;
+	}
+	if (err == 0 && memchr_inv(vaddr, POISON_FREE, PAGE_SIZE)) {
+		pr_err("Write via GGTT mmap did not land in backing store\n");
+		err = -EINVAL;
+	}
+	i915_gem_object_unpin_map(obj);
+
+out:
+	i915_gem_object_put(obj);
+	return err;
+}
+
 int i915_gem_mman_live_selftests(struct drm_i915_private *i915)
 {
 	static const struct i915_subtest tests[] = {
 		SUBTEST(igt_partial_tiling),
 		SUBTEST(igt_smoke_tiling),
 		SUBTEST(igt_mmap_offset_exhaustion),
+		SUBTEST(igt_mmap_gtt),
 	};
 
 	return i915_subtests(tests, i915);
diff --git a/drivers/gpu/drm/i915/selftests/igt_mmap.c b/drivers/gpu/drm/i915/selftests/igt_mmap.c
new file mode 100644
index 000000000000..f5bc80e92573
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_mmap.c
@@ -0,0 +1,39 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include <drm/drm_file.h>
+
+#include "i915_drv.h"
+#include "igt_mmap.h"
+
+unsigned long igt_mmap_node(struct drm_i915_private *i915,
+			    struct drm_vma_offset_node *node,
+			    unsigned long addr,
+			    unsigned long prot,
+			    unsigned long flags)
+{
+	struct file *file;
+	int err;
+
+	/* Pretend to open("/dev/dri/card0") */
+	file = anon_drm_getfile(i915->drm.primary, O_RDWR);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
+
+	err = drm_vma_node_allow(node, file->private_data);
+	if (err) {
+		addr = err;
+		goto out_file;
+	}
+
+	addr = vm_mmap(file, addr, drm_vma_node_size(node) << PAGE_SHIFT,
+		       prot, flags, drm_vma_node_offset_addr(node));
+
+	drm_vma_node_revoke(node, file->private_data);
+out_file:
+	fput(file);
+	return addr;
+}
diff --git a/drivers/gpu/drm/i915/selftests/igt_mmap.h b/drivers/gpu/drm/i915/selftests/igt_mmap.h
new file mode 100644
index 000000000000..6e716cb59d7e
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_mmap.h
@@ -0,0 +1,19 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef IGT_MMAP_H
+#define IGT_MMAP_H
+
+struct drm_i915_private;
+struct drm_vma_offset_node;
+
+unsigned long igt_mmap_node(struct drm_i915_private *i915,
+			    struct drm_vma_offset_node *node,
+			    unsigned long addr,
+			    unsigned long prot,
+			    unsigned long flags);
+
+#endif /* IGT_MMAP_H */
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* [Intel-gfx] [PATCH 2/3] drm/i915/selftests: Wrap vm_mmap() around GEM objects
@ 2019-11-06 10:07   ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:07 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

Provide a utility function to create a vma corresponding to an mmap() of
our device. And use it to exercise the equivalent of userspace
performing a GTT mmap of our objects.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
---
 drivers/gpu/drm/i915/Makefile                 |  1 +
 .../drm/i915/gem/selftests/i915_gem_mman.c    | 97 +++++++++++++++++++
 drivers/gpu/drm/i915/selftests/igt_mmap.c     | 39 ++++++++
 drivers/gpu/drm/i915/selftests/igt_mmap.h     | 19 ++++
 4 files changed, 156 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/selftests/igt_mmap.c
 create mode 100644 drivers/gpu/drm/i915/selftests/igt_mmap.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 90dcf09f52cc..e0fd10c0cfb8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -259,6 +259,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
 	selftests/i915_selftest.o \
 	selftests/igt_flush_test.o \
 	selftests/igt_live_test.o \
+	selftests/igt_mmap.o \
 	selftests/igt_reset.o \
 	selftests/igt_spinner.o
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 29b2077b73d2..11a99d5d2ff8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -12,6 +12,7 @@
 #include "i915_selftest.h"
 #include "selftests/i915_random.h"
 #include "selftests/igt_flush_test.h"
+#include "selftests/igt_mmap.h"
 
 struct tile {
 	unsigned int width;
@@ -694,12 +695,108 @@ static int igt_mmap_offset_exhaustion(void *arg)
 	goto out;
 }
 
+#define expand32(x) (((x) << 0) | ((x) << 8) | ((x) << 16) | ((x) << 24))
+static int igt_mmap_gtt(void *arg)
+{
+	struct drm_i915_private *i915 = arg;
+	struct drm_i915_gem_object *obj;
+	struct vm_area_struct *area;
+	unsigned long addr;
+	void *vaddr;
+	int err, i;
+
+	obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+	if (IS_ERR(obj))
+		return PTR_ERR(obj);
+
+	vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+	if (IS_ERR(vaddr)) {
+		err = PTR_ERR(vaddr);
+		goto out;
+	}
+	memset(vaddr, POISON_INUSE, PAGE_SIZE);
+	i915_gem_object_flush_map(obj);
+	i915_gem_object_unpin_map(obj);
+
+	err = create_mmap_offset(obj);
+	if (err)
+		goto out;
+
+	addr = igt_mmap_node(i915, &obj->base.vma_node,
+			     0, PROT_WRITE, MAP_SHARED);
+	if (IS_ERR_VALUE(addr)) {
+		err = addr;
+		goto out;
+	}
+
+	pr_info("igt_mmap(obj:gtt) @ %lx\n", addr);
+
+	area = find_vma(current->mm, addr);
+	if (!area) {
+		pr_err("Did not create a vm_area_struct for the mmap\n");
+		err = -EINVAL;
+		goto out_unmap;
+	}
+
+	if (area->vm_private_data != obj) {
+		pr_err("vm_area_struct did not point back to our object!\n");
+		err = -EINVAL;
+		goto out_unmap;
+	}
+
+	for (i = 0; i < PAGE_SIZE / sizeof(u32); i++) {
+		u32 __user *ux = u64_to_user_ptr((u64)(addr + i * sizeof*(ux)));
+		u32 x;
+
+		if (get_user(x, ux)) {
+			pr_err("Unable to read from GTT mmap, offset:%zd\n",
+			       i * sizeof(x));
+			err = -EFAULT;
+			break;
+		}
+
+		if (x != expand32(POISON_INUSE)) {
+			pr_err("Read incorrect value from GTT mmap, offset:%zd, found:%x, expected:%x\n",
+			       i * sizeof(x), x, expand32(POISON_INUSE));
+			err = -EINVAL;
+			break;
+		}
+
+		x = expand32(POISON_FREE);
+		if (put_user(x, ux)) {
+			pr_err("Unable to write to GTT mmap, offset:%zd\n",
+			       i * sizeof(x));
+			err = -EFAULT;
+			break;
+		}
+	}
+
+out_unmap:
+	vm_munmap(addr, PAGE_SIZE);
+
+	vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
+	if (IS_ERR(vaddr)) {
+		err = PTR_ERR(vaddr);
+		goto out;
+	}
+	if (err == 0 && memchr_inv(vaddr, POISON_FREE, PAGE_SIZE)) {
+		pr_err("Write via GGTT mmap did not land in backing store\n");
+		err = -EINVAL;
+	}
+	i915_gem_object_unpin_map(obj);
+
+out:
+	i915_gem_object_put(obj);
+	return err;
+}
+
 int i915_gem_mman_live_selftests(struct drm_i915_private *i915)
 {
 	static const struct i915_subtest tests[] = {
 		SUBTEST(igt_partial_tiling),
 		SUBTEST(igt_smoke_tiling),
 		SUBTEST(igt_mmap_offset_exhaustion),
+		SUBTEST(igt_mmap_gtt),
 	};
 
 	return i915_subtests(tests, i915);
diff --git a/drivers/gpu/drm/i915/selftests/igt_mmap.c b/drivers/gpu/drm/i915/selftests/igt_mmap.c
new file mode 100644
index 000000000000..f5bc80e92573
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_mmap.c
@@ -0,0 +1,39 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include <drm/drm_file.h>
+
+#include "i915_drv.h"
+#include "igt_mmap.h"
+
+unsigned long igt_mmap_node(struct drm_i915_private *i915,
+			    struct drm_vma_offset_node *node,
+			    unsigned long addr,
+			    unsigned long prot,
+			    unsigned long flags)
+{
+	struct file *file;
+	int err;
+
+	/* Pretend to open("/dev/dri/card0") */
+	file = anon_drm_getfile(i915->drm.primary, O_RDWR);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
+
+	err = drm_vma_node_allow(node, file->private_data);
+	if (err) {
+		addr = err;
+		goto out_file;
+	}
+
+	addr = vm_mmap(file, addr, drm_vma_node_size(node) << PAGE_SHIFT,
+		       prot, flags, drm_vma_node_offset_addr(node));
+
+	drm_vma_node_revoke(node, file->private_data);
+out_file:
+	fput(file);
+	return addr;
+}
diff --git a/drivers/gpu/drm/i915/selftests/igt_mmap.h b/drivers/gpu/drm/i915/selftests/igt_mmap.h
new file mode 100644
index 000000000000..6e716cb59d7e
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_mmap.h
@@ -0,0 +1,19 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef IGT_MMAP_H
+#define IGT_MMAP_H
+
+struct drm_i915_private;
+struct drm_vma_offset_node;
+
+unsigned long igt_mmap_node(struct drm_i915_private *i915,
+			    struct drm_vma_offset_node *node,
+			    unsigned long addr,
+			    unsigned long prot,
+			    unsigned long flags);
+
+#endif /* IGT_MMAP_H */
-- 
2.24.0

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

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

* [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 10:07   ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:07 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

Currently the drm_prime mmap fallback uses a mock struct file to provide
the file pointer into the backend mmap routine. Now that we can create
fully fledged anonymous struct file around the drm device, put it to
use.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 0814211b0f3f..5faa63713ec8 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
  */
 int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
 {
-	struct drm_file *priv;
-	struct file *fil;
+	struct file *file;
 	int ret;
 
 	if (obj->funcs && obj->funcs->mmap) {
@@ -722,30 +721,21 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
 		return 0;
 	}
 
-	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-	fil = kzalloc(sizeof(*fil), GFP_KERNEL);
-	if (!priv || !fil) {
-		ret = -ENOMEM;
-		goto out;
-	}
+	file = anon_drm_getfile(obj->dev->primary, O_RDWR);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
 
-	/* Used by drm_gem_mmap() to lookup the GEM object */
-	priv->minor = obj->dev->primary;
-	fil->private_data = priv;
-
-	ret = drm_vma_node_allow(&obj->vma_node, priv);
+	ret = drm_vma_node_allow(&obj->vma_node, file->private_data);
 	if (ret)
 		goto out;
 
 	vma->vm_pgoff += drm_vma_node_start(&obj->vma_node);
 
-	ret = obj->dev->driver->fops->mmap(fil, vma);
+	ret = file->f_op->mmap(file, vma);
 
-	drm_vma_node_revoke(&obj->vma_node, priv);
+	drm_vma_node_revoke(&obj->vma_node, file->private_data);
 out:
-	kfree(priv);
-	kfree(fil);
-
+	fput(file);
 	return ret;
 }
 EXPORT_SYMBOL(drm_gem_prime_mmap);
-- 
2.24.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* [Intel-gfx] [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 10:07   ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:07 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

Currently the drm_prime mmap fallback uses a mock struct file to provide
the file pointer into the backend mmap routine. Now that we can create
fully fledged anonymous struct file around the drm device, put it to
use.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 0814211b0f3f..5faa63713ec8 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
  */
 int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
 {
-	struct drm_file *priv;
-	struct file *fil;
+	struct file *file;
 	int ret;
 
 	if (obj->funcs && obj->funcs->mmap) {
@@ -722,30 +721,21 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
 		return 0;
 	}
 
-	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-	fil = kzalloc(sizeof(*fil), GFP_KERNEL);
-	if (!priv || !fil) {
-		ret = -ENOMEM;
-		goto out;
-	}
+	file = anon_drm_getfile(obj->dev->primary, O_RDWR);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
 
-	/* Used by drm_gem_mmap() to lookup the GEM object */
-	priv->minor = obj->dev->primary;
-	fil->private_data = priv;
-
-	ret = drm_vma_node_allow(&obj->vma_node, priv);
+	ret = drm_vma_node_allow(&obj->vma_node, file->private_data);
 	if (ret)
 		goto out;
 
 	vma->vm_pgoff += drm_vma_node_start(&obj->vma_node);
 
-	ret = obj->dev->driver->fops->mmap(fil, vma);
+	ret = file->f_op->mmap(file, vma);
 
-	drm_vma_node_revoke(&obj->vma_node, priv);
+	drm_vma_node_revoke(&obj->vma_node, file->private_data);
 out:
-	kfree(priv);
-	kfree(fil);
-
+	fput(file);
 	return ret;
 }
 EXPORT_SYMBOL(drm_gem_prime_mmap);
-- 
2.24.0

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

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

* Re: [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:19   ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 10:19 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> Sometimes we need to create a struct file to wrap a drm_device, as it
> the user were to have opened /dev/dri/card0 but to do so anonymously
> (i.e. for internal use). Provide a utility method to create a struct
> file with the drm_device->driver.fops, that wrap the drm_device.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

For proper internal access we already have drm_client_open, so I think
this has limited (but good use) in selftests only. So
EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
use like drm_file_mock_open?

Aside from this I like.
-Daniel
> ---
>  drivers/gpu/drm/drm_file.c | 39 ++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_file.h     |  3 +++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index ea34bc991858..cc55c0cd5826 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -31,7 +31,9 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include <linux/anon_inodes.h>
>  #include <linux/dma-fence.h>
> +#include <linux/file.h>
>  #include <linux/module.h>
>  #include <linux/pci.h>
>  #include <linux/poll.h>
> @@ -754,3 +756,40 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
>  	spin_unlock_irqrestore(&dev->event_lock, irqflags);
>  }
>  EXPORT_SYMBOL(drm_send_event);
> +
> +/**
> + * anon_drm_getfile - Create a new struct file for the drm device
> + * @minor: drm minor to wrap (e.g. drm_device->primary)
> + * @flags: file creation mode (O_RDWR etc)
> + *
> + * This create a new struct file that wraps a DRM file context around a
> + * DRM minor. This mimicks userspace opening e.g. /dev/dri/card0, but without
> + * invoking userspace. The struct file may be operated on using its f_op
> + * (the drm_device.driver.fops) to mimick userspace operations, or be supplied
> + * to userspace facing functions as an internal/anonymous client.
> + *
> + * RETURNS:
> + * Pointer to newly created struct file, ERR_PTR on failure.
> + */
> +struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags)
> +{
> +	struct drm_device *dev = minor->dev;
> +	struct drm_file *priv;
> +	struct file *file;
> +
> +	priv = drm_file_alloc(minor);
> +	if (IS_ERR(priv))
> +		return ERR_CAST(priv);
> +
> +	file = anon_inode_getfile("drm", dev->driver->fops, priv, flags);
> +	if (IS_ERR(file)) {
> +		drm_file_free(priv);
> +		return file;
> +	}
> +
> +	drm_dev_get(dev);
> +	priv->filp = file;
> +
> +	return file;
> +}
> +EXPORT_SYMBOL(anon_drm_getfile);
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 67af60bb527a..b963535964f7 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -42,6 +42,7 @@ struct dma_fence;
>  struct drm_file;
>  struct drm_device;
>  struct device;
> +struct file;
>  
>  /*
>   * FIXME: Not sure we want to have drm_minor here in the end, but to avoid
> @@ -387,4 +388,6 @@ void drm_event_cancel_free(struct drm_device *dev,
>  void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e);
>  void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
>  
> +struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags);
> +
>  #endif /* _DRM_FILE_H_ */
> -- 
> 2.24.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] 37+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:19   ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 10:19 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> Sometimes we need to create a struct file to wrap a drm_device, as it
> the user were to have opened /dev/dri/card0 but to do so anonymously
> (i.e. for internal use). Provide a utility method to create a struct
> file with the drm_device->driver.fops, that wrap the drm_device.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

For proper internal access we already have drm_client_open, so I think
this has limited (but good use) in selftests only. So
EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
use like drm_file_mock_open?

Aside from this I like.
-Daniel
> ---
>  drivers/gpu/drm/drm_file.c | 39 ++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_file.h     |  3 +++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index ea34bc991858..cc55c0cd5826 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -31,7 +31,9 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include <linux/anon_inodes.h>
>  #include <linux/dma-fence.h>
> +#include <linux/file.h>
>  #include <linux/module.h>
>  #include <linux/pci.h>
>  #include <linux/poll.h>
> @@ -754,3 +756,40 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
>  	spin_unlock_irqrestore(&dev->event_lock, irqflags);
>  }
>  EXPORT_SYMBOL(drm_send_event);
> +
> +/**
> + * anon_drm_getfile - Create a new struct file for the drm device
> + * @minor: drm minor to wrap (e.g. drm_device->primary)
> + * @flags: file creation mode (O_RDWR etc)
> + *
> + * This create a new struct file that wraps a DRM file context around a
> + * DRM minor. This mimicks userspace opening e.g. /dev/dri/card0, but without
> + * invoking userspace. The struct file may be operated on using its f_op
> + * (the drm_device.driver.fops) to mimick userspace operations, or be supplied
> + * to userspace facing functions as an internal/anonymous client.
> + *
> + * RETURNS:
> + * Pointer to newly created struct file, ERR_PTR on failure.
> + */
> +struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags)
> +{
> +	struct drm_device *dev = minor->dev;
> +	struct drm_file *priv;
> +	struct file *file;
> +
> +	priv = drm_file_alloc(minor);
> +	if (IS_ERR(priv))
> +		return ERR_CAST(priv);
> +
> +	file = anon_inode_getfile("drm", dev->driver->fops, priv, flags);
> +	if (IS_ERR(file)) {
> +		drm_file_free(priv);
> +		return file;
> +	}
> +
> +	drm_dev_get(dev);
> +	priv->filp = file;
> +
> +	return file;
> +}
> +EXPORT_SYMBOL(anon_drm_getfile);
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 67af60bb527a..b963535964f7 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -42,6 +42,7 @@ struct dma_fence;
>  struct drm_file;
>  struct drm_device;
>  struct device;
> +struct file;
>  
>  /*
>   * FIXME: Not sure we want to have drm_minor here in the end, but to avoid
> @@ -387,4 +388,6 @@ void drm_event_cancel_free(struct drm_device *dev,
>  void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e);
>  void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
>  
> +struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags);
> +
>  #endif /* _DRM_FILE_H_ */
> -- 
> 2.24.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] 37+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:19   ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 10:19 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> Sometimes we need to create a struct file to wrap a drm_device, as it
> the user were to have opened /dev/dri/card0 but to do so anonymously
> (i.e. for internal use). Provide a utility method to create a struct
> file with the drm_device->driver.fops, that wrap the drm_device.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

For proper internal access we already have drm_client_open, so I think
this has limited (but good use) in selftests only. So
EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
use like drm_file_mock_open?

Aside from this I like.
-Daniel
> ---
>  drivers/gpu/drm/drm_file.c | 39 ++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_file.h     |  3 +++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index ea34bc991858..cc55c0cd5826 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -31,7 +31,9 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include <linux/anon_inodes.h>
>  #include <linux/dma-fence.h>
> +#include <linux/file.h>
>  #include <linux/module.h>
>  #include <linux/pci.h>
>  #include <linux/poll.h>
> @@ -754,3 +756,40 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
>  	spin_unlock_irqrestore(&dev->event_lock, irqflags);
>  }
>  EXPORT_SYMBOL(drm_send_event);
> +
> +/**
> + * anon_drm_getfile - Create a new struct file for the drm device
> + * @minor: drm minor to wrap (e.g. drm_device->primary)
> + * @flags: file creation mode (O_RDWR etc)
> + *
> + * This create a new struct file that wraps a DRM file context around a
> + * DRM minor. This mimicks userspace opening e.g. /dev/dri/card0, but without
> + * invoking userspace. The struct file may be operated on using its f_op
> + * (the drm_device.driver.fops) to mimick userspace operations, or be supplied
> + * to userspace facing functions as an internal/anonymous client.
> + *
> + * RETURNS:
> + * Pointer to newly created struct file, ERR_PTR on failure.
> + */
> +struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags)
> +{
> +	struct drm_device *dev = minor->dev;
> +	struct drm_file *priv;
> +	struct file *file;
> +
> +	priv = drm_file_alloc(minor);
> +	if (IS_ERR(priv))
> +		return ERR_CAST(priv);
> +
> +	file = anon_inode_getfile("drm", dev->driver->fops, priv, flags);
> +	if (IS_ERR(file)) {
> +		drm_file_free(priv);
> +		return file;
> +	}
> +
> +	drm_dev_get(dev);
> +	priv->filp = file;
> +
> +	return file;
> +}
> +EXPORT_SYMBOL(anon_drm_getfile);
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 67af60bb527a..b963535964f7 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -42,6 +42,7 @@ struct dma_fence;
>  struct drm_file;
>  struct drm_device;
>  struct device;
> +struct file;
>  
>  /*
>   * FIXME: Not sure we want to have drm_minor here in the end, but to avoid
> @@ -387,4 +388,6 @@ void drm_event_cancel_free(struct drm_device *dev,
>  void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e);
>  void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
>  
> +struct file *anon_drm_getfile(struct drm_minor *minor, unsigned int flags);
> +
>  #endif /* _DRM_FILE_H_ */
> -- 
> 2.24.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] 37+ messages in thread

* Re: [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 10:21     ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 10:21 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> Currently the drm_prime mmap fallback uses a mock struct file to provide
> the file pointer into the backend mmap routine. Now that we can create
> fully fledged anonymous struct file around the drm device, put it to
> use.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
>  1 file changed, 8 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 0814211b0f3f..5faa63713ec8 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
>   */
>  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
>  {
> -	struct drm_file *priv;
> -	struct file *fil;
> +	struct file *file;
>  	int ret;
>  
>  	if (obj->funcs && obj->funcs->mmap) {

obj->funcs->mmap is the new way of doing this (and hopefully finally
something clean), I'd really like to retire the below hack outright.

Plus I'm not sure why you need an anon inode here? If a driver needs this
for unmap_mapping_range or similar I think it'd be better to try and make
something work cleanly for obj->funcs->mmap.
-Daniel

> @@ -722,30 +721,21 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
>  		return 0;
>  	}
>  
> -	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> -	fil = kzalloc(sizeof(*fil), GFP_KERNEL);
> -	if (!priv || !fil) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> +	file = anon_drm_getfile(obj->dev->primary, O_RDWR);
> +	if (IS_ERR(file))
> +		return PTR_ERR(file);
>  
> -	/* Used by drm_gem_mmap() to lookup the GEM object */
> -	priv->minor = obj->dev->primary;
> -	fil->private_data = priv;
> -
> -	ret = drm_vma_node_allow(&obj->vma_node, priv);
> +	ret = drm_vma_node_allow(&obj->vma_node, file->private_data);
>  	if (ret)
>  		goto out;
>  
>  	vma->vm_pgoff += drm_vma_node_start(&obj->vma_node);
>  
> -	ret = obj->dev->driver->fops->mmap(fil, vma);
> +	ret = file->f_op->mmap(file, vma);
>  
> -	drm_vma_node_revoke(&obj->vma_node, priv);
> +	drm_vma_node_revoke(&obj->vma_node, file->private_data);
>  out:
> -	kfree(priv);
> -	kfree(fil);
> -
> +	fput(file);
>  	return ret;
>  }
>  EXPORT_SYMBOL(drm_gem_prime_mmap);
> -- 
> 2.24.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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] 37+ messages in thread

* Re: [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 10:21     ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 10:21 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> Currently the drm_prime mmap fallback uses a mock struct file to provide
> the file pointer into the backend mmap routine. Now that we can create
> fully fledged anonymous struct file around the drm device, put it to
> use.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
>  1 file changed, 8 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 0814211b0f3f..5faa63713ec8 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
>   */
>  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
>  {
> -	struct drm_file *priv;
> -	struct file *fil;
> +	struct file *file;
>  	int ret;
>  
>  	if (obj->funcs && obj->funcs->mmap) {

obj->funcs->mmap is the new way of doing this (and hopefully finally
something clean), I'd really like to retire the below hack outright.

Plus I'm not sure why you need an anon inode here? If a driver needs this
for unmap_mapping_range or similar I think it'd be better to try and make
something work cleanly for obj->funcs->mmap.
-Daniel

> @@ -722,30 +721,21 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
>  		return 0;
>  	}
>  
> -	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> -	fil = kzalloc(sizeof(*fil), GFP_KERNEL);
> -	if (!priv || !fil) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> +	file = anon_drm_getfile(obj->dev->primary, O_RDWR);
> +	if (IS_ERR(file))
> +		return PTR_ERR(file);
>  
> -	/* Used by drm_gem_mmap() to lookup the GEM object */
> -	priv->minor = obj->dev->primary;
> -	fil->private_data = priv;
> -
> -	ret = drm_vma_node_allow(&obj->vma_node, priv);
> +	ret = drm_vma_node_allow(&obj->vma_node, file->private_data);
>  	if (ret)
>  		goto out;
>  
>  	vma->vm_pgoff += drm_vma_node_start(&obj->vma_node);
>  
> -	ret = obj->dev->driver->fops->mmap(fil, vma);
> +	ret = file->f_op->mmap(file, vma);
>  
> -	drm_vma_node_revoke(&obj->vma_node, priv);
> +	drm_vma_node_revoke(&obj->vma_node, file->private_data);
>  out:
> -	kfree(priv);
> -	kfree(fil);
> -
> +	fput(file);
>  	return ret;
>  }
>  EXPORT_SYMBOL(drm_gem_prime_mmap);
> -- 
> 2.24.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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] 37+ messages in thread

* Re: [Intel-gfx] [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 10:21     ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 10:21 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> Currently the drm_prime mmap fallback uses a mock struct file to provide
> the file pointer into the backend mmap routine. Now that we can create
> fully fledged anonymous struct file around the drm device, put it to
> use.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
>  1 file changed, 8 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 0814211b0f3f..5faa63713ec8 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
>   */
>  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
>  {
> -	struct drm_file *priv;
> -	struct file *fil;
> +	struct file *file;
>  	int ret;
>  
>  	if (obj->funcs && obj->funcs->mmap) {

obj->funcs->mmap is the new way of doing this (and hopefully finally
something clean), I'd really like to retire the below hack outright.

Plus I'm not sure why you need an anon inode here? If a driver needs this
for unmap_mapping_range or similar I think it'd be better to try and make
something work cleanly for obj->funcs->mmap.
-Daniel

> @@ -722,30 +721,21 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
>  		return 0;
>  	}
>  
> -	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> -	fil = kzalloc(sizeof(*fil), GFP_KERNEL);
> -	if (!priv || !fil) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> +	file = anon_drm_getfile(obj->dev->primary, O_RDWR);
> +	if (IS_ERR(file))
> +		return PTR_ERR(file);
>  
> -	/* Used by drm_gem_mmap() to lookup the GEM object */
> -	priv->minor = obj->dev->primary;
> -	fil->private_data = priv;
> -
> -	ret = drm_vma_node_allow(&obj->vma_node, priv);
> +	ret = drm_vma_node_allow(&obj->vma_node, file->private_data);
>  	if (ret)
>  		goto out;
>  
>  	vma->vm_pgoff += drm_vma_node_start(&obj->vma_node);
>  
> -	ret = obj->dev->driver->fops->mmap(fil, vma);
> +	ret = file->f_op->mmap(file, vma);
>  
> -	drm_vma_node_revoke(&obj->vma_node, priv);
> +	drm_vma_node_revoke(&obj->vma_node, file->private_data);
>  out:
> -	kfree(priv);
> -	kfree(fil);
> -
> +	fput(file);
>  	return ret;
>  }
>  EXPORT_SYMBOL(drm_gem_prime_mmap);
> -- 
> 2.24.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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] 37+ messages in thread

* Re: [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:26     ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:26 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 10:19:50)
> On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > Sometimes we need to create a struct file to wrap a drm_device, as it
> > the user were to have opened /dev/dri/card0 but to do so anonymously
> > (i.e. for internal use). Provide a utility method to create a struct
> > file with the drm_device->driver.fops, that wrap the drm_device.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> For proper internal access we already have drm_client_open, so I think
> this has limited (but good use) in selftests only. So
> EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> use like drm_file_mock_open?

I found the example in drm_gem_prime_mmap() that was doing the same trick,
and the trick of being able to instantiate new struct file and install a
fd whenever seems like it will come in handy... Just lacking the third
user at the moment to claim generality.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:26     ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:26 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 10:19:50)
> On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > Sometimes we need to create a struct file to wrap a drm_device, as it
> > the user were to have opened /dev/dri/card0 but to do so anonymously
> > (i.e. for internal use). Provide a utility method to create a struct
> > file with the drm_device->driver.fops, that wrap the drm_device.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> For proper internal access we already have drm_client_open, so I think
> this has limited (but good use) in selftests only. So
> EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> use like drm_file_mock_open?

I found the example in drm_gem_prime_mmap() that was doing the same trick,
and the trick of being able to instantiate new struct file and install a
fd whenever seems like it will come in handy... Just lacking the third
user at the moment to claim generality.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:26     ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:26 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 10:19:50)
> On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > Sometimes we need to create a struct file to wrap a drm_device, as it
> > the user were to have opened /dev/dri/card0 but to do so anonymously
> > (i.e. for internal use). Provide a utility method to create a struct
> > file with the drm_device->driver.fops, that wrap the drm_device.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> For proper internal access we already have drm_client_open, so I think
> this has limited (but good use) in selftests only. So
> EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> use like drm_file_mock_open?

I found the example in drm_gem_prime_mmap() that was doing the same trick,
and the trick of being able to instantiate new struct file and install a
fd whenever seems like it will come in handy... Just lacking the third
user at the moment to claim generality.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:42       ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:42 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Chris Wilson (2019-11-06 10:26:48)
> Quoting Daniel Vetter (2019-11-06 10:19:50)
> > On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > > Sometimes we need to create a struct file to wrap a drm_device, as it
> > > the user were to have opened /dev/dri/card0 but to do so anonymously
> > > (i.e. for internal use). Provide a utility method to create a struct
> > > file with the drm_device->driver.fops, that wrap the drm_device.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > For proper internal access we already have drm_client_open, so I think
> > this has limited (but good use) in selftests only. So
> > EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> > use like drm_file_mock_open?
> 
> I found the example in drm_gem_prime_mmap() that was doing the same trick,
> and the trick of being able to instantiate new struct file and install a
> fd whenever seems like it will come in handy... Just lacking the third
> user at the moment to claim generality.

The closest example I found in the spirit of creating a new drm_device
struct file and installing it is drm_mode_create_lease_ioctl() that uses
file_clone_open() for this purpose. The argument there would be whether
cloning the (file->f_path, file->f_flags, file->f_cred) is appropriate
versus an anonymous inode. I think cloning the credentials seems correct
for leasing.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:42       ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:42 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Chris Wilson (2019-11-06 10:26:48)
> Quoting Daniel Vetter (2019-11-06 10:19:50)
> > On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > > Sometimes we need to create a struct file to wrap a drm_device, as it
> > > the user were to have opened /dev/dri/card0 but to do so anonymously
> > > (i.e. for internal use). Provide a utility method to create a struct
> > > file with the drm_device->driver.fops, that wrap the drm_device.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > For proper internal access we already have drm_client_open, so I think
> > this has limited (but good use) in selftests only. So
> > EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> > use like drm_file_mock_open?
> 
> I found the example in drm_gem_prime_mmap() that was doing the same trick,
> and the trick of being able to instantiate new struct file and install a
> fd whenever seems like it will come in handy... Just lacking the third
> user at the moment to claim generality.

The closest example I found in the spirit of creating a new drm_device
struct file and installing it is drm_mode_create_lease_ioctl() that uses
file_clone_open() for this purpose. The argument there would be whether
cloning the (file->f_path, file->f_flags, file->f_cred) is appropriate
versus an anonymous inode. I think cloning the credentials seems correct
for leasing.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 10:42       ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:42 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Chris Wilson (2019-11-06 10:26:48)
> Quoting Daniel Vetter (2019-11-06 10:19:50)
> > On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > > Sometimes we need to create a struct file to wrap a drm_device, as it
> > > the user were to have opened /dev/dri/card0 but to do so anonymously
> > > (i.e. for internal use). Provide a utility method to create a struct
> > > file with the drm_device->driver.fops, that wrap the drm_device.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > For proper internal access we already have drm_client_open, so I think
> > this has limited (but good use) in selftests only. So
> > EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> > use like drm_file_mock_open?
> 
> I found the example in drm_gem_prime_mmap() that was doing the same trick,
> and the trick of being able to instantiate new struct file and install a
> fd whenever seems like it will come in handy... Just lacking the third
> user at the moment to claim generality.

The closest example I found in the spirit of creating a new drm_device
struct file and installing it is drm_mode_create_lease_ioctl() that uses
file_clone_open() for this purpose. The argument there would be whether
cloning the (file->f_path, file->f_flags, file->f_cred) is appropriate
versus an anonymous inode. I think cloning the credentials seems correct
for leasing.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 10:45       ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:45 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 10:21:57)
> On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > the file pointer into the backend mmap routine. Now that we can create
> > fully fledged anonymous struct file around the drm device, put it to
> > use.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> >  1 file changed, 8 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 0814211b0f3f..5faa63713ec8 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> >   */
> >  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> >  {
> > -     struct drm_file *priv;
> > -     struct file *fil;
> > +     struct file *file;
> >       int ret;
> >  
> >       if (obj->funcs && obj->funcs->mmap) {
> 
> obj->funcs->mmap is the new way of doing this (and hopefully finally
> something clean), I'd really like to retire the below hack outright.
> 
> Plus I'm not sure why you need an anon inode here? If a driver needs this
> for unmap_mapping_range or similar I think it'd be better to try and make
> something work cleanly for obj->funcs->mmap.

It's faking one currently. If the fake is not good enough, you are
playing whack-a-mole until you finally do create a fully fledged file.

If you are going to the trouble of having to create a struct file to
provide to the fallback routines, might as well avoid stinky code :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 10:45       ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:45 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 10:21:57)
> On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > the file pointer into the backend mmap routine. Now that we can create
> > fully fledged anonymous struct file around the drm device, put it to
> > use.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> >  1 file changed, 8 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 0814211b0f3f..5faa63713ec8 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> >   */
> >  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> >  {
> > -     struct drm_file *priv;
> > -     struct file *fil;
> > +     struct file *file;
> >       int ret;
> >  
> >       if (obj->funcs && obj->funcs->mmap) {
> 
> obj->funcs->mmap is the new way of doing this (and hopefully finally
> something clean), I'd really like to retire the below hack outright.
> 
> Plus I'm not sure why you need an anon inode here? If a driver needs this
> for unmap_mapping_range or similar I think it'd be better to try and make
> something work cleanly for obj->funcs->mmap.

It's faking one currently. If the fake is not good enough, you are
playing whack-a-mole until you finally do create a fully fledged file.

If you are going to the trouble of having to create a struct file to
provide to the fallback routines, might as well avoid stinky code :)
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 10:45       ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 10:45 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 10:21:57)
> On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > the file pointer into the backend mmap routine. Now that we can create
> > fully fledged anonymous struct file around the drm device, put it to
> > use.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> >  1 file changed, 8 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 0814211b0f3f..5faa63713ec8 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> >   */
> >  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> >  {
> > -     struct drm_file *priv;
> > -     struct file *fil;
> > +     struct file *file;
> >       int ret;
> >  
> >       if (obj->funcs && obj->funcs->mmap) {
> 
> obj->funcs->mmap is the new way of doing this (and hopefully finally
> something clean), I'd really like to retire the below hack outright.
> 
> Plus I'm not sure why you need an anon inode here? If a driver needs this
> for unmap_mapping_range or similar I think it'd be better to try and make
> something work cleanly for obj->funcs->mmap.

It's faking one currently. If the fake is not good enough, you are
playing whack-a-mole until you finally do create a fully fledged file.

If you are going to the trouble of having to create a struct file to
provide to the fallback routines, might as well avoid stinky code :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 11:24   ` Patchwork
  0 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2019-11-06 11:24 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
URL   : https://patchwork.freedesktop.org/series/69048/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
115c40d7fea3 drm: Expose a method for creating anonymous struct file around drm_minor
208177262fa1 drm/i915/selftests: Wrap vm_mmap() around GEM objects
-:41: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#41: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:698:
+#define expand32(x) (((x) << 0) | ((x) << 8) | ((x) << 16) | ((x) << 24))

-:91: ERROR:SPACING: space required before that '*' (ctx:VxV)
#91: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:748:
+		u32 __user *ux = u64_to_user_ptr((u64)(addr + i * sizeof*(ux)));
 		                                                        ^

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

-:152: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1
#152: FILE: drivers/gpu/drm/i915/selftests/igt_mmap.c:1:
+/*

-:153: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead
#153: FILE: drivers/gpu/drm/i915/selftests/igt_mmap.c:2:
+ * SPDX-License-Identifier: MIT

-:197: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1
#197: FILE: drivers/gpu/drm/i915/selftests/igt_mmap.h:1:
+/*

-:198: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead
#198: FILE: drivers/gpu/drm/i915/selftests/igt_mmap.h:2:
+ * SPDX-License-Identifier: MIT

total: 1 errors, 5 warnings, 1 checks, 180 lines checked
5c5552478a77 drm/prime: Use anon_drm_getfile() for an internal drm struct file

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

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

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 11:24   ` Patchwork
  0 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2019-11-06 11:24 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
URL   : https://patchwork.freedesktop.org/series/69048/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
115c40d7fea3 drm: Expose a method for creating anonymous struct file around drm_minor
208177262fa1 drm/i915/selftests: Wrap vm_mmap() around GEM objects
-:41: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#41: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:698:
+#define expand32(x) (((x) << 0) | ((x) << 8) | ((x) << 16) | ((x) << 24))

-:91: ERROR:SPACING: space required before that '*' (ctx:VxV)
#91: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:748:
+		u32 __user *ux = u64_to_user_ptr((u64)(addr + i * sizeof*(ux)));
 		                                                        ^

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

-:152: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1
#152: FILE: drivers/gpu/drm/i915/selftests/igt_mmap.c:1:
+/*

-:153: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead
#153: FILE: drivers/gpu/drm/i915/selftests/igt_mmap.c:2:
+ * SPDX-License-Identifier: MIT

-:197: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1
#197: FILE: drivers/gpu/drm/i915/selftests/igt_mmap.h:1:
+/*

-:198: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead
#198: FILE: drivers/gpu/drm/i915/selftests/igt_mmap.h:2:
+ * SPDX-License-Identifier: MIT

total: 1 errors, 5 warnings, 1 checks, 180 lines checked
5c5552478a77 drm/prime: Use anon_drm_getfile() for an internal drm struct file

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

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

* ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 11:44   ` Patchwork
  0 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2019-11-06 11:44 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
URL   : https://patchwork.freedesktop.org/series/69048/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7266 -> Patchwork_15149
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_exec@basic:
    - fi-icl-u3:          [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/fi-icl-u3/igt@gem_ctx_exec@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/fi-icl-u3/igt@gem_ctx_exec@basic.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [PASS][3] -> [FAIL][4] ([fdo#111407])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
#### Possible fixes ####

  * igt@gem_flink_basic@double-flink:
    - fi-icl-u3:          [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/fi-icl-u3/igt@gem_flink_basic@double-flink.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/fi-icl-u3/igt@gem_flink_basic@double-flink.html

  * igt@kms_frontbuffer_tracking@basic:
    - {fi-icl-guc}:       [FAIL][7] ([fdo#103167]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/fi-icl-guc/igt@kms_frontbuffer_tracking@basic.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/fi-icl-guc/igt@kms_frontbuffer_tracking@basic.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407


Participating hosts (50 -> 42)
------------------------------

  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7266 -> Patchwork_15149

  CI-20190529: 20190529
  CI_DRM_7266: 1476c64a0b4c7ee43e50f83ba1d6518e60211a36 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5263: 8a5d44dc5e51622cd43f23c2cf24d44c24a0564d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15149: 5c5552478a770720772a796ed7f140872592c341 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5c5552478a77 drm/prime: Use anon_drm_getfile() for an internal drm struct file
208177262fa1 drm/i915/selftests: Wrap vm_mmap() around GEM objects
115c40d7fea3 drm: Expose a method for creating anonymous struct file around drm_minor

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 11:44   ` Patchwork
  0 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2019-11-06 11:44 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
URL   : https://patchwork.freedesktop.org/series/69048/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7266 -> Patchwork_15149
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_exec@basic:
    - fi-icl-u3:          [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/fi-icl-u3/igt@gem_ctx_exec@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/fi-icl-u3/igt@gem_ctx_exec@basic.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [PASS][3] -> [FAIL][4] ([fdo#111407])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
#### Possible fixes ####

  * igt@gem_flink_basic@double-flink:
    - fi-icl-u3:          [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/fi-icl-u3/igt@gem_flink_basic@double-flink.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/fi-icl-u3/igt@gem_flink_basic@double-flink.html

  * igt@kms_frontbuffer_tracking@basic:
    - {fi-icl-guc}:       [FAIL][7] ([fdo#103167]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/fi-icl-guc/igt@kms_frontbuffer_tracking@basic.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/fi-icl-guc/igt@kms_frontbuffer_tracking@basic.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407


Participating hosts (50 -> 42)
------------------------------

  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7266 -> Patchwork_15149

  CI-20190529: 20190529
  CI_DRM_7266: 1476c64a0b4c7ee43e50f83ba1d6518e60211a36 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5263: 8a5d44dc5e51622cd43f23c2cf24d44c24a0564d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15149: 5c5552478a770720772a796ed7f140872592c341 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5c5552478a77 drm/prime: Use anon_drm_getfile() for an internal drm struct file
208177262fa1 drm/i915/selftests: Wrap vm_mmap() around GEM objects
115c40d7fea3 drm: Expose a method for creating anonymous struct file around drm_minor

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 13:06         ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 13:06 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 6, 2019 at 11:45 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Daniel Vetter (2019-11-06 10:21:57)
> > On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > > the file pointer into the backend mmap routine. Now that we can create
> > > fully fledged anonymous struct file around the drm device, put it to
> > > use.
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > ---
> > >  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> > >  1 file changed, 8 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > index 0814211b0f3f..5faa63713ec8 100644
> > > --- a/drivers/gpu/drm/drm_prime.c
> > > +++ b/drivers/gpu/drm/drm_prime.c
> > > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> > >   */
> > >  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> > >  {
> > > -     struct drm_file *priv;
> > > -     struct file *fil;
> > > +     struct file *file;
> > >       int ret;
> > >
> > >       if (obj->funcs && obj->funcs->mmap) {
> >
> > obj->funcs->mmap is the new way of doing this (and hopefully finally
> > something clean), I'd really like to retire the below hack outright.
> >
> > Plus I'm not sure why you need an anon inode here? If a driver needs this
> > for unmap_mapping_range or similar I think it'd be better to try and make
> > something work cleanly for obj->funcs->mmap.
>
> It's faking one currently. If the fake is not good enough, you are
> playing whack-a-mole until you finally do create a fully fledged file.
>
> If you are going to the trouble of having to create a struct file to
> provide to the fallback routines, might as well avoid stinky code :)

We're currently not faking the inode at all, we're just using the one
that comes with the dma-buf. So distinct from the drm_device file, and
hence unmap_mapping_range won't work (or at least doing that on the
drm_device inode wont shoot down the ptes for redirected dma-buf
mmaps). obj->funcs->mmap has the same issue.

But since all current users of this don't expect unmap_mapping_range
to work correctly, it's not an real issue. If that changes then imo we
should fix up the obj->funcs->mmap path to have the correct inode, not
the deprecated path you're updating here. But since there's no patch 4
in this series to start using this for i915 or someone else, I'm not
seeing the point.

Or am I blind? At least slightly confused,
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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] 37+ messages in thread

* Re: [Intel-gfx] [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 13:06         ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 13:06 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 6, 2019 at 11:45 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Daniel Vetter (2019-11-06 10:21:57)
> > On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > > the file pointer into the backend mmap routine. Now that we can create
> > > fully fledged anonymous struct file around the drm device, put it to
> > > use.
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > ---
> > >  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> > >  1 file changed, 8 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > index 0814211b0f3f..5faa63713ec8 100644
> > > --- a/drivers/gpu/drm/drm_prime.c
> > > +++ b/drivers/gpu/drm/drm_prime.c
> > > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> > >   */
> > >  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> > >  {
> > > -     struct drm_file *priv;
> > > -     struct file *fil;
> > > +     struct file *file;
> > >       int ret;
> > >
> > >       if (obj->funcs && obj->funcs->mmap) {
> >
> > obj->funcs->mmap is the new way of doing this (and hopefully finally
> > something clean), I'd really like to retire the below hack outright.
> >
> > Plus I'm not sure why you need an anon inode here? If a driver needs this
> > for unmap_mapping_range or similar I think it'd be better to try and make
> > something work cleanly for obj->funcs->mmap.
>
> It's faking one currently. If the fake is not good enough, you are
> playing whack-a-mole until you finally do create a fully fledged file.
>
> If you are going to the trouble of having to create a struct file to
> provide to the fallback routines, might as well avoid stinky code :)

We're currently not faking the inode at all, we're just using the one
that comes with the dma-buf. So distinct from the drm_device file, and
hence unmap_mapping_range won't work (or at least doing that on the
drm_device inode wont shoot down the ptes for redirected dma-buf
mmaps). obj->funcs->mmap has the same issue.

But since all current users of this don't expect unmap_mapping_range
to work correctly, it's not an real issue. If that changes then imo we
should fix up the obj->funcs->mmap path to have the correct inode, not
the deprecated path you're updating here. But since there's no patch 4
in this series to start using this for i915 or someone else, I'm not
seeing the point.

Or am I blind? At least slightly confused,
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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] 37+ messages in thread

* Re: [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 13:08         ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 13:08 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 6, 2019 at 11:43 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Chris Wilson (2019-11-06 10:26:48)
> > Quoting Daniel Vetter (2019-11-06 10:19:50)
> > > On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > > > Sometimes we need to create a struct file to wrap a drm_device, as it
> > > > the user were to have opened /dev/dri/card0 but to do so anonymously
> > > > (i.e. for internal use). Provide a utility method to create a struct
> > > > file with the drm_device->driver.fops, that wrap the drm_device.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > >
> > > For proper internal access we already have drm_client_open, so I think
> > > this has limited (but good use) in selftests only. So
> > > EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> > > use like drm_file_mock_open?
> >
> > I found the example in drm_gem_prime_mmap() that was doing the same trick,
> > and the trick of being able to instantiate new struct file and install a
> > fd whenever seems like it will come in handy... Just lacking the third
> > user at the moment to claim generality.
>
> The closest example I found in the spirit of creating a new drm_device
> struct file and installing it is drm_mode_create_lease_ioctl() that uses
> file_clone_open() for this purpose. The argument there would be whether
> cloning the (file->f_path, file->f_flags, file->f_cred) is appropriate
> versus an anonymous inode. I think cloning the credentials seems correct
> for leasing.

Hm ... I think we want the clone for this one here too. Otherwise we
get the wrong inode, and then unmap_mapping_range wont work correctly,
and we cant use this for selftests. That's the only case where I think
we do actually need the file/inode to be functional. For anything else
the drm_client internal api gets away without the file/inode stuff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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] 37+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 13:08         ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 13:08 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 6, 2019 at 11:43 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Chris Wilson (2019-11-06 10:26:48)
> > Quoting Daniel Vetter (2019-11-06 10:19:50)
> > > On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > > > Sometimes we need to create a struct file to wrap a drm_device, as it
> > > > the user were to have opened /dev/dri/card0 but to do so anonymously
> > > > (i.e. for internal use). Provide a utility method to create a struct
> > > > file with the drm_device->driver.fops, that wrap the drm_device.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > >
> > > For proper internal access we already have drm_client_open, so I think
> > > this has limited (but good use) in selftests only. So
> > > EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> > > use like drm_file_mock_open?
> >
> > I found the example in drm_gem_prime_mmap() that was doing the same trick,
> > and the trick of being able to instantiate new struct file and install a
> > fd whenever seems like it will come in handy... Just lacking the third
> > user at the moment to claim generality.
>
> The closest example I found in the spirit of creating a new drm_device
> struct file and installing it is drm_mode_create_lease_ioctl() that uses
> file_clone_open() for this purpose. The argument there would be whether
> cloning the (file->f_path, file->f_flags, file->f_cred) is appropriate
> versus an anonymous inode. I think cloning the credentials seems correct
> for leasing.

Hm ... I think we want the clone for this one here too. Otherwise we
get the wrong inode, and then unmap_mapping_range wont work correctly,
and we cant use this for selftests. That's the only case where I think
we do actually need the file/inode to be functional. For anything else
the drm_client internal api gets away without the file/inode stuff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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] 37+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-06 13:08         ` Daniel Vetter
  0 siblings, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2019-11-06 13:08 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, dri-devel

On Wed, Nov 6, 2019 at 11:43 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Chris Wilson (2019-11-06 10:26:48)
> > Quoting Daniel Vetter (2019-11-06 10:19:50)
> > > On Wed, Nov 06, 2019 at 10:07:14AM +0000, Chris Wilson wrote:
> > > > Sometimes we need to create a struct file to wrap a drm_device, as it
> > > > the user were to have opened /dev/dri/card0 but to do so anonymously
> > > > (i.e. for internal use). Provide a utility method to create a struct
> > > > file with the drm_device->driver.fops, that wrap the drm_device.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > >
> > > For proper internal access we already have drm_client_open, so I think
> > > this has limited (but good use) in selftests only. So
> > > EXPORT_SYMBOL_FOR_TESTS_ONLY plus maybe a clearer name for the intended
> > > use like drm_file_mock_open?
> >
> > I found the example in drm_gem_prime_mmap() that was doing the same trick,
> > and the trick of being able to instantiate new struct file and install a
> > fd whenever seems like it will come in handy... Just lacking the third
> > user at the moment to claim generality.
>
> The closest example I found in the spirit of creating a new drm_device
> struct file and installing it is drm_mode_create_lease_ioctl() that uses
> file_clone_open() for this purpose. The argument there would be whether
> cloning the (file->f_path, file->f_flags, file->f_cred) is appropriate
> versus an anonymous inode. I think cloning the credentials seems correct
> for leasing.

Hm ... I think we want the clone for this one here too. Otherwise we
get the wrong inode, and then unmap_mapping_range wont work correctly,
and we cant use this for selftests. That's the only case where I think
we do actually need the file/inode to be functional. For anything else
the drm_client internal api gets away without the file/inode stuff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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] 37+ messages in thread

* Re: [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 13:17           ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 13:17 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 13:06:26)
> On Wed, Nov 6, 2019 at 11:45 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > Quoting Daniel Vetter (2019-11-06 10:21:57)
> > > On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > > > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > > > the file pointer into the backend mmap routine. Now that we can create
> > > > fully fledged anonymous struct file around the drm device, put it to
> > > > use.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > ---
> > > >  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> > > >  1 file changed, 8 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > > index 0814211b0f3f..5faa63713ec8 100644
> > > > --- a/drivers/gpu/drm/drm_prime.c
> > > > +++ b/drivers/gpu/drm/drm_prime.c
> > > > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> > > >   */
> > > >  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> > > >  {
> > > > -     struct drm_file *priv;
> > > > -     struct file *fil;
> > > > +     struct file *file;
> > > >       int ret;
> > > >
> > > >       if (obj->funcs && obj->funcs->mmap) {
> > >
> > > obj->funcs->mmap is the new way of doing this (and hopefully finally
> > > something clean), I'd really like to retire the below hack outright.
> > >
> > > Plus I'm not sure why you need an anon inode here? If a driver needs this
> > > for unmap_mapping_range or similar I think it'd be better to try and make
> > > something work cleanly for obj->funcs->mmap.
> >
> > It's faking one currently. If the fake is not good enough, you are
> > playing whack-a-mole until you finally do create a fully fledged file.
> >
> > If you are going to the trouble of having to create a struct file to
> > provide to the fallback routines, might as well avoid stinky code :)
> 
> We're currently not faking the inode at all, we're just using the one
> that comes with the dma-buf. So distinct from the drm_device file, and
> hence unmap_mapping_range won't work (or at least doing that on the
> drm_device inode wont shoot down the ptes for redirected dma-buf
> mmaps). obj->funcs->mmap has the same issue.
> 
> But since all current users of this don't expect unmap_mapping_range
> to work correctly, it's not an real issue. If that changes then imo we
> should fix up the obj->funcs->mmap path to have the correct inode, not
> the deprecated path you're updating here. But since there's no patch 4
> in this series to start using this for i915 or someone else, I'm not
> seeing the point.

There's a bug in anon_drm_inode() in that it requires an extra:

+       /* Everyone shares a single global address space */
+       file->f_mapping = dev->anon_inode->i_mapping;

I'm up to 5 patches now, but only i915/selftests & this here fallback as
direct users.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 13:17           ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 13:17 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 13:06:26)
> On Wed, Nov 6, 2019 at 11:45 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > Quoting Daniel Vetter (2019-11-06 10:21:57)
> > > On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > > > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > > > the file pointer into the backend mmap routine. Now that we can create
> > > > fully fledged anonymous struct file around the drm device, put it to
> > > > use.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > ---
> > > >  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> > > >  1 file changed, 8 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > > index 0814211b0f3f..5faa63713ec8 100644
> > > > --- a/drivers/gpu/drm/drm_prime.c
> > > > +++ b/drivers/gpu/drm/drm_prime.c
> > > > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> > > >   */
> > > >  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> > > >  {
> > > > -     struct drm_file *priv;
> > > > -     struct file *fil;
> > > > +     struct file *file;
> > > >       int ret;
> > > >
> > > >       if (obj->funcs && obj->funcs->mmap) {
> > >
> > > obj->funcs->mmap is the new way of doing this (and hopefully finally
> > > something clean), I'd really like to retire the below hack outright.
> > >
> > > Plus I'm not sure why you need an anon inode here? If a driver needs this
> > > for unmap_mapping_range or similar I think it'd be better to try and make
> > > something work cleanly for obj->funcs->mmap.
> >
> > It's faking one currently. If the fake is not good enough, you are
> > playing whack-a-mole until you finally do create a fully fledged file.
> >
> > If you are going to the trouble of having to create a struct file to
> > provide to the fallback routines, might as well avoid stinky code :)
> 
> We're currently not faking the inode at all, we're just using the one
> that comes with the dma-buf. So distinct from the drm_device file, and
> hence unmap_mapping_range won't work (or at least doing that on the
> drm_device inode wont shoot down the ptes for redirected dma-buf
> mmaps). obj->funcs->mmap has the same issue.
> 
> But since all current users of this don't expect unmap_mapping_range
> to work correctly, it's not an real issue. If that changes then imo we
> should fix up the obj->funcs->mmap path to have the correct inode, not
> the deprecated path you're updating here. But since there's no patch 4
> in this series to start using this for i915 or someone else, I'm not
> seeing the point.

There's a bug in anon_drm_inode() in that it requires an extra:

+       /* Everyone shares a single global address space */
+       file->f_mapping = dev->anon_inode->i_mapping;

I'm up to 5 patches now, but only i915/selftests & this here fallback as
direct users.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file
@ 2019-11-06 13:17           ` Chris Wilson
  0 siblings, 0 replies; 37+ messages in thread
From: Chris Wilson @ 2019-11-06 13:17 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

Quoting Daniel Vetter (2019-11-06 13:06:26)
> On Wed, Nov 6, 2019 at 11:45 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > Quoting Daniel Vetter (2019-11-06 10:21:57)
> > > On Wed, Nov 06, 2019 at 10:07:16AM +0000, Chris Wilson wrote:
> > > > Currently the drm_prime mmap fallback uses a mock struct file to provide
> > > > the file pointer into the backend mmap routine. Now that we can create
> > > > fully fledged anonymous struct file around the drm device, put it to
> > > > use.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > ---
> > > >  drivers/gpu/drm/drm_prime.c | 26 ++++++++------------------
> > > >  1 file changed, 8 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > > index 0814211b0f3f..5faa63713ec8 100644
> > > > --- a/drivers/gpu/drm/drm_prime.c
> > > > +++ b/drivers/gpu/drm/drm_prime.c
> > > > @@ -709,8 +709,7 @@ EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> > > >   */
> > > >  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> > > >  {
> > > > -     struct drm_file *priv;
> > > > -     struct file *fil;
> > > > +     struct file *file;
> > > >       int ret;
> > > >
> > > >       if (obj->funcs && obj->funcs->mmap) {
> > >
> > > obj->funcs->mmap is the new way of doing this (and hopefully finally
> > > something clean), I'd really like to retire the below hack outright.
> > >
> > > Plus I'm not sure why you need an anon inode here? If a driver needs this
> > > for unmap_mapping_range or similar I think it'd be better to try and make
> > > something work cleanly for obj->funcs->mmap.
> >
> > It's faking one currently. If the fake is not good enough, you are
> > playing whack-a-mole until you finally do create a fully fledged file.
> >
> > If you are going to the trouble of having to create a struct file to
> > provide to the fallback routines, might as well avoid stinky code :)
> 
> We're currently not faking the inode at all, we're just using the one
> that comes with the dma-buf. So distinct from the drm_device file, and
> hence unmap_mapping_range won't work (or at least doing that on the
> drm_device inode wont shoot down the ptes for redirected dma-buf
> mmaps). obj->funcs->mmap has the same issue.
> 
> But since all current users of this don't expect unmap_mapping_range
> to work correctly, it's not an real issue. If that changes then imo we
> should fix up the obj->funcs->mmap path to have the correct inode, not
> the deprecated path you're updating here. But since there's no patch 4
> in this series to start using this for i915 or someone else, I'm not
> seeing the point.

There's a bug in anon_drm_inode() in that it requires an extra:

+       /* Everyone shares a single global address space */
+       file->f_mapping = dev->anon_inode->i_mapping;

I'm up to 5 patches now, but only i915/selftests & this here fallback as
direct users.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✗ Fi.CI.IGT: failure for series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-07  8:40   ` Patchwork
  0 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2019-11-07  8:40 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
URL   : https://patchwork.freedesktop.org/series/69048/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7266_full -> Patchwork_15149_full
====================================================

Summary
-------

  **FAILURE**

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

  

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

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

### IGT changes ###

#### Possible regressions ####

  * igt@gem_sync@basic-store-all:
    - shard-tglb:         NOTRUN -> [INCOMPLETE][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb9/igt@gem_sync@basic-store-all.html

  * igt@runner@aborted:
    - shard-kbl:          NOTRUN -> [FAIL][2]
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-kbl7/igt@runner@aborted.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_exec@basic-invalid-context-vcs1:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#112080]) +21 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb1/igt@gem_ctx_exec@basic-invalid-context-vcs1.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb3/igt@gem_ctx_exec@basic-invalid-context-vcs1.html

  * igt@gem_ctx_isolation@vcs0-s3:
    - shard-tglb:         [PASS][5] -> [INCOMPLETE][6] ([fdo#111832])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb9/igt@gem_ctx_isolation@vcs0-s3.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb1/igt@gem_ctx_isolation@vcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-queued:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080]) +7 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@gem_ctx_persistence@vcs1-queued.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb5/igt@gem_ctx_persistence@vcs1-queued.html

  * igt@gem_ctx_shared@q-smoketest-all:
    - shard-tglb:         [PASS][9] -> [INCOMPLETE][10] ([fdo#111735])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb5/igt@gem_ctx_shared@q-smoketest-all.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb8/igt@gem_ctx_shared@q-smoketest-all.html

  * igt@gem_eio@in-flight-suspend:
    - shard-tglb:         [PASS][11] -> [INCOMPLETE][12] ([fdo#111832] / [fdo#111850] / [fdo#112081])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb3/igt@gem_eio@in-flight-suspend.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb5/igt@gem_eio@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][13] -> [SKIP][14] ([fdo#110854])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@gem_exec_balancer@smoke.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb7/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_parallel@fds:
    - shard-tglb:         [PASS][15] -> [INCOMPLETE][16] ([fdo#111867])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb9/igt@gem_exec_parallel@fds.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb6/igt@gem_exec_parallel@fds.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [PASS][17] -> [SKIP][18] ([fdo#112146]) +11 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb6/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb1/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_sync@basic-many-each:
    - shard-tglb:         [PASS][19] -> [INCOMPLETE][20] ([fdo#111647] / [fdo#111998])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb7/igt@gem_sync@basic-many-each.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb2/igt@gem_sync@basic-many-each.html

  * igt@gem_userptr_blits@dmabuf-sync:
    - shard-hsw:          [PASS][21] -> [DMESG-WARN][22] ([fdo#111870])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-hsw5/igt@gem_userptr_blits@dmabuf-sync.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-hsw6/igt@gem_userptr_blits@dmabuf-sync.html

  * igt@i915_selftest@live_gt_timelines:
    - shard-tglb:         [PASS][23] -> [INCOMPLETE][24] ([fdo#111831])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb1/igt@i915_selftest@live_gt_timelines.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb6/igt@i915_selftest@live_gt_timelines.html

  * igt@i915_selftest@live_hangcheck:
    - shard-hsw:          [PASS][25] -> [DMESG-FAIL][26] ([fdo#111991])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-hsw5/igt@i915_selftest@live_hangcheck.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-hsw2/igt@i915_selftest@live_hangcheck.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-tglb:         [PASS][27] -> [INCOMPLETE][28] ([fdo#111832] / [fdo#111850]) +1 similar issue
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb8/igt@i915_suspend@fence-restore-tiled2untiled.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb1/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-skl:          [PASS][29] -> [INCOMPLETE][30] ([fdo#110741])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl6/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-tglb:         [PASS][31] -> [INCOMPLETE][32] ([fdo#111747] / [fdo#111832] / [fdo#111850])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb5/igt@kms_fbcon_fbt@fbc-suspend.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb5/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-kbl:          [PASS][33] -> [DMESG-WARN][34] ([fdo#108566]) +3 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-kbl2/igt@kms_flip@flip-vs-suspend-interruptible.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
    - shard-iclb:         [PASS][35] -> [FAIL][36] ([fdo#103167]) +5 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite:
    - shard-tglb:         [PASS][37] -> [FAIL][38] ([fdo#103167]) +3 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb5/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
    - shard-apl:          [PASS][39] -> [DMESG-WARN][40] ([fdo#108566])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-apl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][41] -> [FAIL][42] ([fdo#108145] / [fdo#110403])
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [PASS][43] -> [FAIL][44] ([fdo#103166])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb4/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_sprite_mmap_gtt:
    - shard-iclb:         [PASS][45] -> [SKIP][46] ([fdo#109441]) +1 similar issue
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb5/igt@kms_psr@psr2_sprite_mmap_gtt.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [PASS][47] -> [SKIP][48] ([fdo#109276]) +26 similar issues
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb1/igt@prime_vgem@fence-wait-bsd2.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb8/igt@prime_vgem@fence-wait-bsd2.html

  
#### Possible fixes ####

  * igt@gem_busy@busy-vcs1:
    - shard-iclb:         [SKIP][49] ([fdo#112080]) -> [PASS][50] +14 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb7/igt@gem_busy@busy-vcs1.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb4/igt@gem_busy@busy-vcs1.html

  * igt@gem_ctx_isolation@vcs1-none:
    - shard-iclb:         [SKIP][51] ([fdo#109276] / [fdo#112080]) -> [PASS][52] +2 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb6/igt@gem_ctx_isolation@vcs1-none.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb1/igt@gem_ctx_isolation@vcs1-none.html

  * igt@gem_ctx_switch@queue-heavy:
    - shard-tglb:         [INCOMPLETE][53] ([fdo#111747]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb6/igt@gem_ctx_switch@queue-heavy.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb8/igt@gem_ctx_switch@queue-heavy.html

  * igt@gem_exec_async@concurrent-writes-bsd:
    - shard-iclb:         [SKIP][55] ([fdo#112146]) -> [PASS][56] +2 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@gem_exec_async@concurrent-writes-bsd.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb7/igt@gem_exec_async@concurrent-writes-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-blt:
    - shard-tglb:         [INCOMPLETE][57] ([fdo#111606] / [fdo#111677]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb6/igt@gem_exec_schedule@preempt-queue-contexts-blt.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb6/igt@gem_exec_schedule@preempt-queue-contexts-blt.html

  * igt@gem_persistent_relocs@forked-thrashing:
    - shard-snb:          [FAIL][59] ([fdo#112037]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-snb1/igt@gem_persistent_relocs@forked-thrashing.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-snb2/igt@gem_persistent_relocs@forked-thrashing.html

  * igt@i915_selftest@mock_requests:
    - shard-skl:          [INCOMPLETE][61] ([fdo#108972]) -> [PASS][62]
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl1/igt@i915_selftest@mock_requests.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl3/igt@i915_selftest@mock_requests.html

  * igt@i915_suspend@fence-restore-untiled:
    - shard-skl:          [INCOMPLETE][63] ([fdo#104108]) -> [PASS][64]
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl7/igt@i915_suspend@fence-restore-untiled.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl4/igt@i915_suspend@fence-restore-untiled.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-kbl:          [DMESG-WARN][65] ([fdo#108566]) -> [PASS][66] +8 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_flip@2x-blocking-wf_vblank:
    - shard-hsw:          [INCOMPLETE][67] ([fdo#103540]) -> [PASS][68]
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-hsw2/igt@kms_flip@2x-blocking-wf_vblank.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-hsw4/igt@kms_flip@2x-blocking-wf_vblank.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-apl:          [DMESG-WARN][69] ([fdo#108566]) -> [PASS][70] +3 similar issues
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-apl3/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
    - shard-iclb:         [FAIL][71] ([fdo#103167]) -> [PASS][72] +3 similar issues
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-tglb:         [INCOMPLETE][73] ([fdo#111832] / [fdo#111850] / [fdo#111884]) -> [PASS][74]
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb2/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb8/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite:
    - shard-tglb:         [FAIL][75] ([fdo#103167]) -> [PASS][76] +1 similar issue
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [FAIL][77] ([fdo#108145] / [fdo#110403]) -> [PASS][78]
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_plane_onoff:
    - shard-iclb:         [SKIP][79] ([fdo#109441]) -> [PASS][80] +2 similar issues
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb1/igt@kms_psr@psr2_cursor_plane_onoff.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html

  * igt@kms_psr@suspend:
    - shard-tglb:         [INCOMPLETE][81] ([fdo#111832] / [fdo#111850]) -> [PASS][82] +1 similar issue
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb2/igt@kms_psr@suspend.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb4/igt@kms_psr@suspend.html

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
    - shard-tglb:         [INCOMPLETE][83] ([fdo#111850]) -> [PASS][84]
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb4/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb9/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html

  * igt@prime_busy@after-bsd2:
    - shard-iclb:         [SKIP][85] ([fdo#109276]) -> [PASS][86] +21 similar issues
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb8/igt@prime_busy@after-bsd2.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb2/igt@prime_busy@after-bsd2.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [FAIL][87] ([fdo#111329]) -> [SKIP][88] ([fdo#109276] / [fdo#112080]) +1 similar issue
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb4/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb8/igt@gem_ctx_isolation@vcs1-nonpriv.html

  * igt@gem_eio@kms:
    - shard-snb:          [DMESG-WARN][89] ([fdo#111781]) -> [INCOMPLETE][90] ([fdo#105411])
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-snb2/igt@gem_eio@kms.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-snb2/igt@gem_eio@kms.html

  * igt@gem_exec_schedule@deep-render:
    - shard-tglb:         [FAIL][91] ([fdo#111646]) -> [INCOMPLETE][92] ([fdo#111671])
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb1/igt@gem_exec_schedule@deep-render.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb1/igt@gem_exec_schedule@deep-render.html

  * igt@gem_mocs_settings@mocs-rc6-bsd2:
    - shard-iclb:         [FAIL][93] ([fdo#111330]) -> [SKIP][94] ([fdo#109276])
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@gem_mocs_settings@mocs-rc6-bsd2.html
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb5/igt@gem_mocs_settings@mocs-rc6-bsd2.html

  * igt@gem_mocs_settings@mocs-reset-bsd2:
    - shard-iclb:         [SKIP][95] ([fdo#109276]) -> [FAIL][96] ([fdo#111330])
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb6/igt@gem_mocs_settings@mocs-reset-bsd2.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb1/igt@gem_mocs_settings@mocs-reset-bsd2.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
    - shard-kbl:          [FAIL][97] ([fdo#112037]) -> [INCOMPLETE][98] ([fdo#103665])
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-kbl6/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-kbl7/igt@gem_persistent_relocs@forked-interruptible-thrashing.html

  * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing:
    - shard-hsw:          [SKIP][99] ([fdo#109271]) -> [SKIP][100] ([fdo#109271] / [fdo#111766])
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-hsw5/igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-hsw1/igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing.html

  * igt@kms_atomic_transition@6x-modeset-transitions-fencing:
    - shard-tglb:         [SKIP][101] ([fdo#112016 ] / [fdo#112021 ]) -> [SKIP][102] ([fdo#112021 ]) +1 similar issue
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb8/igt@kms_atomic_transition@6x-modeset-transitions-fencing.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb9/igt@kms_atomic_transition@6x-modeset-transitions-fencing.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         [SKIP][103] ([fdo#109349]) -> [DMESG-WARN][104] ([fdo#107724])
   [103]: https://i

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
@ 2019-11-07  8:40   ` Patchwork
  0 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2019-11-07  8:40 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm: Expose a method for creating anonymous struct file around drm_minor
URL   : https://patchwork.freedesktop.org/series/69048/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7266_full -> Patchwork_15149_full
====================================================

Summary
-------

  **FAILURE**

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

  

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

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

### IGT changes ###

#### Possible regressions ####

  * igt@gem_sync@basic-store-all:
    - shard-tglb:         NOTRUN -> [INCOMPLETE][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb9/igt@gem_sync@basic-store-all.html

  * igt@runner@aborted:
    - shard-kbl:          NOTRUN -> [FAIL][2]
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-kbl7/igt@runner@aborted.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_exec@basic-invalid-context-vcs1:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#112080]) +21 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb1/igt@gem_ctx_exec@basic-invalid-context-vcs1.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb3/igt@gem_ctx_exec@basic-invalid-context-vcs1.html

  * igt@gem_ctx_isolation@vcs0-s3:
    - shard-tglb:         [PASS][5] -> [INCOMPLETE][6] ([fdo#111832])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb9/igt@gem_ctx_isolation@vcs0-s3.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb1/igt@gem_ctx_isolation@vcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-queued:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080]) +7 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@gem_ctx_persistence@vcs1-queued.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb5/igt@gem_ctx_persistence@vcs1-queued.html

  * igt@gem_ctx_shared@q-smoketest-all:
    - shard-tglb:         [PASS][9] -> [INCOMPLETE][10] ([fdo#111735])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb5/igt@gem_ctx_shared@q-smoketest-all.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb8/igt@gem_ctx_shared@q-smoketest-all.html

  * igt@gem_eio@in-flight-suspend:
    - shard-tglb:         [PASS][11] -> [INCOMPLETE][12] ([fdo#111832] / [fdo#111850] / [fdo#112081])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb3/igt@gem_eio@in-flight-suspend.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb5/igt@gem_eio@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][13] -> [SKIP][14] ([fdo#110854])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@gem_exec_balancer@smoke.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb7/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_parallel@fds:
    - shard-tglb:         [PASS][15] -> [INCOMPLETE][16] ([fdo#111867])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb9/igt@gem_exec_parallel@fds.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb6/igt@gem_exec_parallel@fds.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [PASS][17] -> [SKIP][18] ([fdo#112146]) +11 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb6/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb1/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_sync@basic-many-each:
    - shard-tglb:         [PASS][19] -> [INCOMPLETE][20] ([fdo#111647] / [fdo#111998])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb7/igt@gem_sync@basic-many-each.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb2/igt@gem_sync@basic-many-each.html

  * igt@gem_userptr_blits@dmabuf-sync:
    - shard-hsw:          [PASS][21] -> [DMESG-WARN][22] ([fdo#111870])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-hsw5/igt@gem_userptr_blits@dmabuf-sync.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-hsw6/igt@gem_userptr_blits@dmabuf-sync.html

  * igt@i915_selftest@live_gt_timelines:
    - shard-tglb:         [PASS][23] -> [INCOMPLETE][24] ([fdo#111831])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb1/igt@i915_selftest@live_gt_timelines.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb6/igt@i915_selftest@live_gt_timelines.html

  * igt@i915_selftest@live_hangcheck:
    - shard-hsw:          [PASS][25] -> [DMESG-FAIL][26] ([fdo#111991])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-hsw5/igt@i915_selftest@live_hangcheck.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-hsw2/igt@i915_selftest@live_hangcheck.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-tglb:         [PASS][27] -> [INCOMPLETE][28] ([fdo#111832] / [fdo#111850]) +1 similar issue
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb8/igt@i915_suspend@fence-restore-tiled2untiled.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb1/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-skl:          [PASS][29] -> [INCOMPLETE][30] ([fdo#110741])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl6/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-tglb:         [PASS][31] -> [INCOMPLETE][32] ([fdo#111747] / [fdo#111832] / [fdo#111850])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb5/igt@kms_fbcon_fbt@fbc-suspend.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb5/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-kbl:          [PASS][33] -> [DMESG-WARN][34] ([fdo#108566]) +3 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-kbl2/igt@kms_flip@flip-vs-suspend-interruptible.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
    - shard-iclb:         [PASS][35] -> [FAIL][36] ([fdo#103167]) +5 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite:
    - shard-tglb:         [PASS][37] -> [FAIL][38] ([fdo#103167]) +3 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb5/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
    - shard-apl:          [PASS][39] -> [DMESG-WARN][40] ([fdo#108566])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-apl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][41] -> [FAIL][42] ([fdo#108145] / [fdo#110403])
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [PASS][43] -> [FAIL][44] ([fdo#103166])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb4/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_sprite_mmap_gtt:
    - shard-iclb:         [PASS][45] -> [SKIP][46] ([fdo#109441]) +1 similar issue
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb5/igt@kms_psr@psr2_sprite_mmap_gtt.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [PASS][47] -> [SKIP][48] ([fdo#109276]) +26 similar issues
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb1/igt@prime_vgem@fence-wait-bsd2.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb8/igt@prime_vgem@fence-wait-bsd2.html

  
#### Possible fixes ####

  * igt@gem_busy@busy-vcs1:
    - shard-iclb:         [SKIP][49] ([fdo#112080]) -> [PASS][50] +14 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb7/igt@gem_busy@busy-vcs1.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb4/igt@gem_busy@busy-vcs1.html

  * igt@gem_ctx_isolation@vcs1-none:
    - shard-iclb:         [SKIP][51] ([fdo#109276] / [fdo#112080]) -> [PASS][52] +2 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb6/igt@gem_ctx_isolation@vcs1-none.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb1/igt@gem_ctx_isolation@vcs1-none.html

  * igt@gem_ctx_switch@queue-heavy:
    - shard-tglb:         [INCOMPLETE][53] ([fdo#111747]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb6/igt@gem_ctx_switch@queue-heavy.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb8/igt@gem_ctx_switch@queue-heavy.html

  * igt@gem_exec_async@concurrent-writes-bsd:
    - shard-iclb:         [SKIP][55] ([fdo#112146]) -> [PASS][56] +2 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@gem_exec_async@concurrent-writes-bsd.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb7/igt@gem_exec_async@concurrent-writes-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-blt:
    - shard-tglb:         [INCOMPLETE][57] ([fdo#111606] / [fdo#111677]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb6/igt@gem_exec_schedule@preempt-queue-contexts-blt.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb6/igt@gem_exec_schedule@preempt-queue-contexts-blt.html

  * igt@gem_persistent_relocs@forked-thrashing:
    - shard-snb:          [FAIL][59] ([fdo#112037]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-snb1/igt@gem_persistent_relocs@forked-thrashing.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-snb2/igt@gem_persistent_relocs@forked-thrashing.html

  * igt@i915_selftest@mock_requests:
    - shard-skl:          [INCOMPLETE][61] ([fdo#108972]) -> [PASS][62]
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl1/igt@i915_selftest@mock_requests.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl3/igt@i915_selftest@mock_requests.html

  * igt@i915_suspend@fence-restore-untiled:
    - shard-skl:          [INCOMPLETE][63] ([fdo#104108]) -> [PASS][64]
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl7/igt@i915_suspend@fence-restore-untiled.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl4/igt@i915_suspend@fence-restore-untiled.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-kbl:          [DMESG-WARN][65] ([fdo#108566]) -> [PASS][66] +8 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_flip@2x-blocking-wf_vblank:
    - shard-hsw:          [INCOMPLETE][67] ([fdo#103540]) -> [PASS][68]
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-hsw2/igt@kms_flip@2x-blocking-wf_vblank.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-hsw4/igt@kms_flip@2x-blocking-wf_vblank.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-apl:          [DMESG-WARN][69] ([fdo#108566]) -> [PASS][70] +3 similar issues
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-apl3/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
    - shard-iclb:         [FAIL][71] ([fdo#103167]) -> [PASS][72] +3 similar issues
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-tglb:         [INCOMPLETE][73] ([fdo#111832] / [fdo#111850] / [fdo#111884]) -> [PASS][74]
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb2/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb8/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite:
    - shard-tglb:         [FAIL][75] ([fdo#103167]) -> [PASS][76] +1 similar issue
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [FAIL][77] ([fdo#108145] / [fdo#110403]) -> [PASS][78]
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_plane_onoff:
    - shard-iclb:         [SKIP][79] ([fdo#109441]) -> [PASS][80] +2 similar issues
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb1/igt@kms_psr@psr2_cursor_plane_onoff.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html

  * igt@kms_psr@suspend:
    - shard-tglb:         [INCOMPLETE][81] ([fdo#111832] / [fdo#111850]) -> [PASS][82] +1 similar issue
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb2/igt@kms_psr@suspend.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb4/igt@kms_psr@suspend.html

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
    - shard-tglb:         [INCOMPLETE][83] ([fdo#111850]) -> [PASS][84]
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb4/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb9/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html

  * igt@prime_busy@after-bsd2:
    - shard-iclb:         [SKIP][85] ([fdo#109276]) -> [PASS][86] +21 similar issues
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb8/igt@prime_busy@after-bsd2.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb2/igt@prime_busy@after-bsd2.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [FAIL][87] ([fdo#111329]) -> [SKIP][88] ([fdo#109276] / [fdo#112080]) +1 similar issue
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb4/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb8/igt@gem_ctx_isolation@vcs1-nonpriv.html

  * igt@gem_eio@kms:
    - shard-snb:          [DMESG-WARN][89] ([fdo#111781]) -> [INCOMPLETE][90] ([fdo#105411])
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-snb2/igt@gem_eio@kms.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-snb2/igt@gem_eio@kms.html

  * igt@gem_exec_schedule@deep-render:
    - shard-tglb:         [FAIL][91] ([fdo#111646]) -> [INCOMPLETE][92] ([fdo#111671])
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb1/igt@gem_exec_schedule@deep-render.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb1/igt@gem_exec_schedule@deep-render.html

  * igt@gem_mocs_settings@mocs-rc6-bsd2:
    - shard-iclb:         [FAIL][93] ([fdo#111330]) -> [SKIP][94] ([fdo#109276])
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb2/igt@gem_mocs_settings@mocs-rc6-bsd2.html
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb5/igt@gem_mocs_settings@mocs-rc6-bsd2.html

  * igt@gem_mocs_settings@mocs-reset-bsd2:
    - shard-iclb:         [SKIP][95] ([fdo#109276]) -> [FAIL][96] ([fdo#111330])
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-iclb6/igt@gem_mocs_settings@mocs-reset-bsd2.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-iclb1/igt@gem_mocs_settings@mocs-reset-bsd2.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
    - shard-kbl:          [FAIL][97] ([fdo#112037]) -> [INCOMPLETE][98] ([fdo#103665])
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-kbl6/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-kbl7/igt@gem_persistent_relocs@forked-interruptible-thrashing.html

  * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing:
    - shard-hsw:          [SKIP][99] ([fdo#109271]) -> [SKIP][100] ([fdo#109271] / [fdo#111766])
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-hsw5/igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-hsw1/igt@kms_atomic_transition@3x-modeset-transitions-nonblocking-fencing.html

  * igt@kms_atomic_transition@6x-modeset-transitions-fencing:
    - shard-tglb:         [SKIP][101] ([fdo#112016 ] / [fdo#112021 ]) -> [SKIP][102] ([fdo#112021 ]) +1 similar issue
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7266/shard-tglb8/igt@kms_atomic_transition@6x-modeset-transitions-fencing.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/shard-tglb9/igt@kms_atomic_transition@6x-modeset-transitions-fencing.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         [SKIP][103] ([fdo#109349]) -> [DMESG-WARN][104] ([fdo#107724])
   [103]: https://i

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15149/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

end of thread, other threads:[~2019-11-07  8:40 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-06 10:07 [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor Chris Wilson
2019-11-06 10:07 ` [Intel-gfx] " Chris Wilson
2019-11-06 10:07 ` Chris Wilson
2019-11-06 10:07 ` [PATCH 2/3] drm/i915/selftests: Wrap vm_mmap() around GEM objects Chris Wilson
2019-11-06 10:07   ` [Intel-gfx] " Chris Wilson
2019-11-06 10:07   ` Chris Wilson
2019-11-06 10:07 ` [PATCH 3/3] drm/prime: Use anon_drm_getfile() for an internal drm struct file Chris Wilson
2019-11-06 10:07   ` [Intel-gfx] " Chris Wilson
2019-11-06 10:21   ` Daniel Vetter
2019-11-06 10:21     ` [Intel-gfx] " Daniel Vetter
2019-11-06 10:21     ` Daniel Vetter
2019-11-06 10:45     ` Chris Wilson
2019-11-06 10:45       ` [Intel-gfx] " Chris Wilson
2019-11-06 10:45       ` Chris Wilson
2019-11-06 13:06       ` Daniel Vetter
2019-11-06 13:06         ` [Intel-gfx] " Daniel Vetter
2019-11-06 13:17         ` Chris Wilson
2019-11-06 13:17           ` [Intel-gfx] " Chris Wilson
2019-11-06 13:17           ` Chris Wilson
2019-11-06 10:19 ` [PATCH 1/3] drm: Expose a method for creating anonymous struct file around drm_minor Daniel Vetter
2019-11-06 10:19   ` [Intel-gfx] " Daniel Vetter
2019-11-06 10:19   ` Daniel Vetter
2019-11-06 10:26   ` Chris Wilson
2019-11-06 10:26     ` [Intel-gfx] " Chris Wilson
2019-11-06 10:26     ` Chris Wilson
2019-11-06 10:42     ` Chris Wilson
2019-11-06 10:42       ` [Intel-gfx] " Chris Wilson
2019-11-06 10:42       ` Chris Wilson
2019-11-06 13:08       ` Daniel Vetter
2019-11-06 13:08         ` [Intel-gfx] " Daniel Vetter
2019-11-06 13:08         ` Daniel Vetter
2019-11-06 11:24 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] " Patchwork
2019-11-06 11:24   ` [Intel-gfx] " Patchwork
2019-11-06 11:44 ` ✓ Fi.CI.BAT: success " Patchwork
2019-11-06 11:44   ` [Intel-gfx] " Patchwork
2019-11-07  8:40 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-11-07  8:40   ` [Intel-gfx] " Patchwork

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.