[PATCHv2 0/3] convert i915 to new mount API

[PATCHv2 0/3] convert i915 to new mount API

[Sergey Senozhatsky]

	Hello,

Convert i915 to a new mount API and fix i915_gemfs_init() kernel Oops.

It also appears that we need to EXPORTs put_filesystem(), so i915
can properly put filesystem after it is done with kern_mount().

v2:
- export put_filesystem() [Chris]
- always put_filesystem() in i915_gemfs_init() [Chris]
- improve i915_gemfs_init() error message [Chris]

Sergey Senozhatsky (3):
  fs: export put_filesystem()
  i915: convert to new mount API
  i915: do not leak module ref counter

 drivers/gpu/drm/i915/gem/i915_gemfs.c | 33 +++++++++++++++++++--------
 fs/filesystems.c                      |  1 +
 2 files changed, 25 insertions(+), 9 deletions(-)

-- 
2.22.0

[PATCHv2 0/3] convert i915 to new mount API

[Sergey Senozhatsky]

	Hello,

Convert i915 to a new mount API and fix i915_gemfs_init() kernel Oops.

It also appears that we need to EXPORTs put_filesystem(), so i915
can properly put filesystem after it is done with kern_mount().

v2:
- export put_filesystem() [Chris]
- always put_filesystem() in i915_gemfs_init() [Chris]
- improve i915_gemfs_init() error message [Chris]

Sergey Senozhatsky (3):
  fs: export put_filesystem()
  i915: convert to new mount API
  i915: do not leak module ref counter

 drivers/gpu/drm/i915/gem/i915_gemfs.c | 33 +++++++++++++++++++--------
 fs/filesystems.c                      |  1 +
 2 files changed, 25 insertions(+), 9 deletions(-)

-- 
2.22.0

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

[PATCHv2 1/3] fs: export put_filesystem()

[Sergey Senozhatsky]

Modules can use get_fs_type(), which is exported, but are unable
to put_filesystem(). Export it and let modules to also decrement
corresponding file systems' reference counters.

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
 fs/filesystems.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/filesystems.c b/fs/filesystems.c
index 9135646e41ac..02669839b584 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -45,6 +45,7 @@ void put_filesystem(struct file_system_type *fs)
 {
 	module_put(fs->owner);
 }
+EXPORT_SYMBOL(put_filesystem);
 
 static struct file_system_type **find_filesystem(const char *name, unsigned len)
 {
-- 
2.22.0

[PATCHv2 2/3] i915: convert to new mount API

[Sergey Senozhatsky]

tmpfs does not set ->remount_fs() anymore and its users need
to be converted to new mount API.

 BUG: kernel NULL pointer dereference, address: 0000000000000000
 PF: supervisor instruction fetch in kernel mode
 PF: error_code(0x0010) - not-present page
 RIP: 0010:0x0
 Code: Bad RIP value.
 Call Trace:
  i915_gemfs_init+0x6e/0xa0 [i915]
  i915_gem_init_early+0x76/0x90 [i915]
  i915_driver_probe+0x30a/0x1640 [i915]
  ? kernfs_activate+0x5a/0x80
  ? kernfs_add_one+0xdd/0x130
  pci_device_probe+0x9e/0x110
  really_probe+0xce/0x230
  driver_probe_device+0x4b/0xc0
  device_driver_attach+0x4e/0x60
  __driver_attach+0x47/0xb0
  ? device_driver_attach+0x60/0x60
  bus_for_each_dev+0x61/0x90
  bus_add_driver+0x167/0x1b0
  driver_register+0x67/0xaa

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gem/i915_gemfs.c | 32 +++++++++++++++++++--------
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index 099f3397aada..feedc9242072 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -7,14 +7,17 @@
 #include <linux/fs.h>
 #include <linux/mount.h>
 #include <linux/pagemap.h>
+#include <linux/fs_context.h>
 
 #include "i915_drv.h"
 #include "i915_gemfs.h"
 
 int i915_gemfs_init(struct drm_i915_private *i915)
 {
+	struct fs_context *fc = NULL;
 	struct file_system_type *type;
 	struct vfsmount *gemfs;
+	bool ok = true;
 
 	type = get_fs_type("tmpfs");
 	if (!type)
@@ -36,18 +39,29 @@ int i915_gemfs_init(struct drm_i915_private *i915)
 		struct super_block *sb = gemfs->mnt_sb;
 		/* FIXME: Disabled until we get W/A for read BW issue. */
 		char options[] = "huge=never";
-		int flags = 0;
-		int err;
-
-		err = sb->s_op->remount_fs(sb, &flags, options);
-		if (err) {
-			kern_unmount(gemfs);
-			return err;
-		}
+
+		ok = false;
+		fc = fs_context_for_reconfigure(sb->s_root, 0, 0);
+		if (IS_ERR(fc))
+			goto out;
+
+		if (!fc->ops->parse_monolithic ||
+				fc->ops->parse_monolithic(fc, options))
+			goto out;
+
+		if (fc->ops->reconfigure && !fc->ops->reconfigure(fc))
+			ok = true;
 	}
 
+out:
+	if (!ok)
+		dev_err(i915->drm.dev,
+			"Unable to reconfigure %s. %s\n",
+			"shmemfs for preferred allocation strategy",
+			"Continuing, but performance may suffer");
+	if (!IS_ERR_OR_NULL(fc))
+		put_fs_context(fc);
 	i915->mm.gemfs = gemfs;
-
 	return 0;
 }
 
-- 
2.22.0

[PATCHv2 2/3] i915: convert to new mount API

[Sergey Senozhatsky]

tmpfs does not set ->remount_fs() anymore and its users need
to be converted to new mount API.

 BUG: kernel NULL pointer dereference, address: 0000000000000000
 PF: supervisor instruction fetch in kernel mode
 PF: error_code(0x0010) - not-present page
 RIP: 0010:0x0
 Code: Bad RIP value.
 Call Trace:
  i915_gemfs_init+0x6e/0xa0 [i915]
  i915_gem_init_early+0x76/0x90 [i915]
  i915_driver_probe+0x30a/0x1640 [i915]
  ? kernfs_activate+0x5a/0x80
  ? kernfs_add_one+0xdd/0x130
  pci_device_probe+0x9e/0x110
  really_probe+0xce/0x230
  driver_probe_device+0x4b/0xc0
  device_driver_attach+0x4e/0x60
  __driver_attach+0x47/0xb0
  ? device_driver_attach+0x60/0x60
  bus_for_each_dev+0x61/0x90
  bus_add_driver+0x167/0x1b0
  driver_register+0x67/0xaa

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gem/i915_gemfs.c | 32 +++++++++++++++++++--------
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index 099f3397aada..feedc9242072 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -7,14 +7,17 @@
 #include <linux/fs.h>
 #include <linux/mount.h>
 #include <linux/pagemap.h>
+#include <linux/fs_context.h>
 
 #include "i915_drv.h"
 #include "i915_gemfs.h"
 
 int i915_gemfs_init(struct drm_i915_private *i915)
 {
+	struct fs_context *fc = NULL;
 	struct file_system_type *type;
 	struct vfsmount *gemfs;
+	bool ok = true;
 
 	type = get_fs_type("tmpfs");
 	if (!type)
@@ -36,18 +39,29 @@ int i915_gemfs_init(struct drm_i915_private *i915)
 		struct super_block *sb = gemfs->mnt_sb;
 		/* FIXME: Disabled until we get W/A for read BW issue. */
 		char options[] = "huge=never";
-		int flags = 0;
-		int err;
-
-		err = sb->s_op->remount_fs(sb, &flags, options);
-		if (err) {
-			kern_unmount(gemfs);
-			return err;
-		}
+
+		ok = false;
+		fc = fs_context_for_reconfigure(sb->s_root, 0, 0);
+		if (IS_ERR(fc))
+			goto out;
+
+		if (!fc->ops->parse_monolithic ||
+				fc->ops->parse_monolithic(fc, options))
+			goto out;
+
+		if (fc->ops->reconfigure && !fc->ops->reconfigure(fc))
+			ok = true;
 	}
 
+out:
+	if (!ok)
+		dev_err(i915->drm.dev,
+			"Unable to reconfigure %s. %s\n",
+			"shmemfs for preferred allocation strategy",
+			"Continuing, but performance may suffer");
+	if (!IS_ERR_OR_NULL(fc))
+		put_fs_context(fc);
 	i915->mm.gemfs = gemfs;
-
 	return 0;
 }
 
-- 
2.22.0

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

[PATCHv2 3/3] i915: do not leak module ref counter

[Sergey Senozhatsky]

put_filesystem() must follow get_fs_type().

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
 drivers/gpu/drm/i915/gem/i915_gemfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index feedc9242072..93ac365ce9ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -24,6 +24,7 @@ int i915_gemfs_init(struct drm_i915_private *i915)
 		return -ENODEV;
 
 	gemfs = kern_mount(type);
+	put_filesystem(type);
 	if (IS_ERR(gemfs))
 		return PTR_ERR(gemfs);
 
-- 
2.22.0

✗ Fi.CI.CHECKPATCH: warning for convert i915 to new mount API

[Patchwork]

== Series Details ==

Series: convert i915 to new mount API
URL   : https://patchwork.freedesktop.org/series/64720/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
475186841e5f fs: export put_filesystem()
50698577361e i915: convert to new mount API
-:74: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#74: FILE: drivers/gpu/drm/i915/gem/i915_gemfs.c:49:
+		if (!fc->ops->parse_monolithic ||
+				fc->ops->parse_monolithic(fc, options))

total: 0 errors, 0 warnings, 1 checks, 55 lines checked
b48cd274857d i915: do not leak module ref counter

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

✓ Fi.CI.BAT: success for convert i915 to new mount API

[Patchwork]

== Series Details ==

Series: convert i915 to new mount API
URL   : https://patchwork.freedesktop.org/series/64720/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6630 -> Patchwork_13871
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_mmap_gtt@basic-write-cpu-read-gtt:
    - fi-icl-u3:          [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-icl-u3/igt@gem_mmap_gtt@basic-write-cpu-read-gtt.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-icl-u3/igt@gem_mmap_gtt@basic-write-cpu-read-gtt.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-kbl-7567u:       [PASS][3] -> [WARN][4] ([fdo#109380])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-kbl-7567u/igt@kms_chamelium@common-hpd-after-suspend.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-kbl-7567u/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
    - fi-pnv-d510:        [PASS][5] -> [FAIL][6] ([fdo#100368])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vblank.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
    - fi-kbl-7567u:       [PASS][7] -> [SKIP][8] ([fdo#109271]) +23 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-kbl-7567u/igt@kms_pipe_crc_basic@read-crc-pipe-c.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-kbl-7567u/igt@kms_pipe_crc_basic@read-crc-pipe-c.html

  * igt@prime_vgem@basic-fence-flip:
    - fi-ilk-650:         [PASS][9] -> [DMESG-WARN][10] ([fdo#106387]) +1 similar issue
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-ilk-650/igt@prime_vgem@basic-fence-flip.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-ilk-650/igt@prime_vgem@basic-fence-flip.html

  
#### Possible fixes ####

  * igt@i915_selftest@live_reset:
    - fi-icl-u3:          [INCOMPLETE][11] ([fdo#107713]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-icl-u3/igt@i915_selftest@live_reset.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-icl-u3/igt@i915_selftest@live_reset.html

  * igt@kms_busy@basic-flip-a:
    - fi-kbl-7567u:       [SKIP][13] ([fdo#109271] / [fdo#109278]) -> [PASS][14] +2 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-kbl-7567u/igt@kms_busy@basic-flip-a.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-kbl-7567u/igt@kms_busy@basic-flip-a.html

  * igt@kms_busy@basic-flip-c:
    - fi-kbl-7500u:       [SKIP][15] ([fdo#109271] / [fdo#109278]) -> [PASS][16] +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-kbl-7500u/igt@kms_busy@basic-flip-c.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-kbl-7500u/igt@kms_busy@basic-flip-c.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-icl-u3:          [FAIL][17] ([fdo#103167]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/fi-icl-u3/igt@kms_frontbuffer_tracking@basic.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/fi-icl-u3/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#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096


Participating hosts (53 -> 46)
------------------------------

  Missing    (7): fi-kbl-soraka fi-byt-squawks fi-bsw-cyan fi-icl-y fi-icl-guc fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6630 -> Patchwork_13871

  CI-20190529: 20190529
  CI_DRM_6630: cd167abc41ff46cc6139a2773e3a3f3d91d1469d @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5120: b3138fbea79d5d7935e53530b90efe3e816236f4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13871: b48cd274857d3ef72566c752fe4c12d19f257fe3 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b48cd274857d i915: do not leak module ref counter
50698577361e i915: convert to new mount API
475186841e5f fs: export put_filesystem()

== Logs ==

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

Re: [PATCHv2 2/3] i915: convert to new mount API

[Al Viro]

On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> tmpfs does not set ->remount_fs() anymore and its users need
> to be converted to new mount API.

Could you explain why the devil do you bother with remount at all?
Why not pass the right options when mounting the damn thing?

Re: [PATCHv2 2/3] i915: convert to new mount API

[Al Viro]

On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote:
> On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > tmpfs does not set ->remount_fs() anymore and its users need
> > to be converted to new mount API.
> 
> Could you explain why the devil do you bother with remount at all?
> Why not pass the right options when mounting the damn thing?

... and while we are at it, I really wonder what's going on with
that gemfs thing - among the other things, this is the only
user of shmem_file_setup_with_mnt().  Sure, you want your own
options, but that brings another question - is there any reason
for having the huge=... per-superblock rather than per-file?

After all, the readers of ->huge in mm/shmem.c are
mm/shmem.c:582:     (shmem_huge == SHMEM_HUGE_FORCE || sbinfo->huge) &&
	is_huge_enabled(), sbinfo is an explicit argument

mm/shmem.c:1799:        switch (sbinfo->huge) {
	shmem_getpage_gfp(), sbinfo comes from inode

mm/shmem.c:2113:                if (SHMEM_SB(sb)->huge == SHMEM_HUGE_NEVER)
	shmem_get_unmapped_area(), sb comes from file

mm/shmem.c:3531:        if (sbinfo->huge)
mm/shmem.c:3532:                seq_printf(seq, ",huge=%s", shmem_format_huge(sbinfo->huge));
	->show_options()
mm/shmem.c:3880:        switch (sbinfo->huge) {
	shmem_huge_enabled(), sbinfo comes from an inode

And the only caller of is_huge_enabled() is shmem_getattr(), with sbinfo
picked from inode.

So is there any reason why the hugepage policy can't be per-file, with
the current being overridable default?

Re: [PATCHv2 0/3] convert i915 to new mount API

[Sedat Dilek]

On Mon, Aug 5, 2019 at 6:05 PM Sergey Senozhatsky
<sergey.senozhatsky@gmail.com> wrote:
>
>         Hello,
>
> Convert i915 to a new mount API and fix i915_gemfs_init() kernel Oops.
>
> It also appears that we need to EXPORTs put_filesystem(), so i915
> can properly put filesystem after it is done with kern_mount().
>
> v2:
> - export put_filesystem() [Chris]
> - always put_filesystem() in i915_gemfs_init() [Chris]
> - improve i915_gemfs_init() error message [Chris]
>
> Sergey Senozhatsky (3):
>   fs: export put_filesystem()
>   i915: convert to new mount API
>   i915: do not leak module ref counter
>

Fee free to add:

Reported-by: Sedat Dilek <sedat.dilek@gmail.com>

[1] https://lore.kernel.org/lkml/CA+icZUXh068m8UFeHDXCKDi0YfL2Z=WoONy7J7DJLqAT1CZ+rQ@mail.gmail.com/

>  drivers/gpu/drm/i915/gem/i915_gemfs.c | 33 +++++++++++++++++++--------
>  fs/filesystems.c                      |  1 +
>  2 files changed, 25 insertions(+), 9 deletions(-)
>
> --
> 2.22.0
>

✓ Fi.CI.IGT: success for convert i915 to new mount API

[Patchwork]

== Series Details ==

Series: convert i915 to new mount API
URL   : https://patchwork.freedesktop.org/series/64720/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6630_full -> Patchwork_13871_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@rcs0-s3:
    - shard-apl:          [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +4 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-apl4/igt@gem_ctx_isolation@rcs0-s3.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-apl5/igt@gem_ctx_isolation@rcs0-s3.html

  * igt@i915_pm_rpm@i2c:
    - shard-hsw:          [PASS][3] -> [FAIL][4] ([fdo#104097])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-hsw7/igt@i915_pm_rpm@i2c.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-hsw6/igt@i915_pm_rpm@i2c.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-skl:          [PASS][5] -> [FAIL][6] ([fdo#105363])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl3/igt@kms_flip@flip-vs-expired-vblank.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl4/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_flip@plain-flip-fb-recreate:
    - shard-kbl:          [PASS][7] -> [FAIL][8] ([fdo#100368])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-kbl3/igt@kms_flip@plain-flip-fb-recreate.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-kbl3/igt@kms_flip@plain-flip-fb-recreate.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-blt:
    - shard-iclb:         [PASS][9] -> [FAIL][10] ([fdo#103167]) +2 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-iclb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-blt.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-iclb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-blt.html

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
    - shard-skl:          [PASS][11] -> [FAIL][12] ([fdo#108145])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [PASS][13] -> [FAIL][14] ([fdo#108145] / [fdo#110403])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl7/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl7/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
    - shard-skl:          [PASS][15] -> [DMESG-WARN][16] ([fdo#106885])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl6/igt@kms_plane_multiple@atomic-pipe-c-tiling-yf.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl3/igt@kms_plane_multiple@atomic-pipe-c-tiling-yf.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-iclb1/igt@kms_psr@psr2_sprite_plane_move.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@rcs0-s3:
    - shard-kbl:          [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] +3 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-kbl6/igt@gem_ctx_isolation@rcs0-s3.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-kbl3/igt@gem_ctx_isolation@rcs0-s3.html

  * igt@gem_tiled_swapping@non-threaded:
    - shard-glk:          [DMESG-WARN][21] ([fdo#108686]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-glk6/igt@gem_tiled_swapping@non-threaded.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-glk3/igt@gem_tiled_swapping@non-threaded.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-apl:          [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +2 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-apl5/igt@gem_workarounds@suspend-resume-context.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-apl5/igt@gem_workarounds@suspend-resume-context.html

  * igt@kms_color@pipe-c-ctm-0-5:
    - shard-skl:          [FAIL][25] ([fdo#108682]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl3/igt@kms_color@pipe-c-ctm-0-5.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl5/igt@kms_color@pipe-c-ctm-0-5.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-skl:          [INCOMPLETE][27] ([fdo#110741]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl2/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl9/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-dpms:
    - shard-skl:          [FAIL][29] ([fdo#103232]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl3/igt@kms_cursor_crc@pipe-c-cursor-dpms.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl5/igt@kms_cursor_crc@pipe-c-cursor-dpms.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size:
    - shard-iclb:         [INCOMPLETE][31] ([fdo#107713]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-iclb7/igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-iclb4/igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
    - shard-skl:          [FAIL][33] ([fdo#102670]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl4/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl8/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt:
    - shard-iclb:         [FAIL][35] ([fdo#103167]) -> [PASS][36] +3 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][37] ([fdo#108145] / [fdo#110403]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [SKIP][39] ([fdo#109642] / [fdo#111068]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-iclb3/igt@kms_psr2_su@frontbuffer.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-iclb2/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@psr2_basic:
    - shard-iclb:         [SKIP][41] ([fdo#109441]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-iclb1/igt@kms_psr@psr2_basic.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-iclb2/igt@kms_psr@psr2_basic.html

  * igt@perf@short-reads:
    - shard-glk:          [FAIL][43] ([fdo#103183]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-glk6/igt@perf@short-reads.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-glk3/igt@perf@short-reads.html

  
#### Warnings ####

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-pgflip-blt:
    - shard-skl:          [FAIL][45] ([fdo#108040]) -> [FAIL][46] ([fdo#103167])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-pgflip-blt.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl10/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-pgflip-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt:
    - shard-skl:          [FAIL][47] ([fdo#103167]) -> [FAIL][48] ([fdo#108040])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6630/shard-skl8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13871/shard-skl10/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt.html

  
  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#102670]: https://bugs.freedesktop.org/show_bug.cgi?id=102670
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103183]: https://bugs.freedesktop.org/show_bug.cgi?id=103183
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#104097]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#106885]: https://bugs.freedesktop.org/show_bug.cgi?id=106885
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108040]: https://bugs.freedesktop.org/show_bug.cgi?id=108040
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108682]: https://bugs.freedesktop.org/show_bug.cgi?id=108682
  [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#110741]: https://bugs.freedesktop.org/show_bug.cgi?id=110741
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6630 -> Patchwork_13871

  CI-20190529: 20190529
  CI_DRM_6630: cd167abc41ff46cc6139a2773e3a3f3d91d1469d @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5120: b3138fbea79d5d7935e53530b90efe3e816236f4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13871: b48cd274857d3ef72566c752fe4c12d19f257fe3 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [PATCHv2 2/3] i915: convert to new mount API

[Al Viro]

On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote:
> On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > tmpfs does not set ->remount_fs() anymore and its users need
> > to be converted to new mount API.
> 
> Could you explain why the devil do you bother with remount at all?
> Why not pass the right options when mounting the damn thing?

Incidentally, the only remaining modular user of get_fs_type() is the
same i915_gemfs.c.  And I wonder if we should aim for unexporting
the damn thing instead of exporting put_filesystem()...

Note that users in tomoyo and apparmor are bogus - they are in the
instances of ill-defined method that needs to be split and moved,
with the lookups (fs type included) replaced with callers passing
the values they look up and will end up using.

IOW, outside of core VFS we have very few legitimate users, and the
one in kernel/trace might be better off as vfs_submount_by_name().

Re: [PATCHv2 2/3] i915: convert to new mount API

[Sergey Senozhatsky]

On (08/05/19 19:12), Al Viro wrote:
[..]
> On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > tmpfs does not set ->remount_fs() anymore and its users need
> > to be converted to new mount API.
> 
> Could you explain why the devil do you bother with remount at all?

I would redirect this question to i915 developers. As far as I know
i915 performance suffers with huge pages enabled.

> Why not pass the right options when mounting the damn thing?

vfs_kern_mount()? It still requires struct file_system_type, which
we need to get and put.

	-ss

Re: [PATCHv2 2/3] i915: convert to new mount API

[Hugh Dickins]

On Mon, 5 Aug 2019, Al Viro wrote:
> On Mon, Aug 05, 2019 at 07:12:55PM +0100, Al Viro wrote:
> > On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote:
> > > tmpfs does not set ->remount_fs() anymore and its users need
> > > to be converted to new mount API.
> > 
> > Could you explain why the devil do you bother with remount at all?
> > Why not pass the right options when mounting the damn thing?
> 
> ... and while we are at it, I really wonder what's going on with
> that gemfs thing - among the other things, this is the only
> user of shmem_file_setup_with_mnt().  Sure, you want your own
> options, but that brings another question - is there any reason
> for having the huge=... per-superblock rather than per-file?

Yes: we want a default for how files of that superblock are to
allocate their pages, without people having to fcntl or advise
each of their files.

Setting aside the weirder options (within_size, advise) and emergency/
testing override (shmem_huge), we want files on an ordinary default
tmpfs (huge=never) to be allocated with small pages (so users with
access to that filesystem will not consume, and will not waste time
and space on consuming, the more valuable huge pages); but files on a
huge=always tmpfs to be allocated with huge pages whenever possible.

Or am I missing your point?  Yes, hugeness can certainly be decided
differently per-file, or even per-extent of file.  That is already
made possible through "judicious" use of madvise MADV_HUGEPAGE and
MADV_NOHUGEPAGE on mmaps of the file, carried over from anon THP.

Though personally I'm averse to managing "f"objects through
"m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
on the virtual address of a mapping, but the huge-or-not alignment of
that mapping must have been decided previously).  In Google we do use
fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
one day I'll get to upstreaming those.

Hugh

> 
> After all, the readers of ->huge in mm/shmem.c are
> mm/shmem.c:582:     (shmem_huge == SHMEM_HUGE_FORCE || sbinfo->huge) &&
> 	is_huge_enabled(), sbinfo is an explicit argument
> 
> mm/shmem.c:1799:        switch (sbinfo->huge) {
> 	shmem_getpage_gfp(), sbinfo comes from inode
> 
> mm/shmem.c:2113:                if (SHMEM_SB(sb)->huge == SHMEM_HUGE_NEVER)
> 	shmem_get_unmapped_area(), sb comes from file
> 
> mm/shmem.c:3531:        if (sbinfo->huge)
> mm/shmem.c:3532:                seq_printf(seq, ",huge=%s", shmem_format_huge(sbinfo->huge));
> 	->show_options()
> mm/shmem.c:3880:        switch (sbinfo->huge) {
> 	shmem_huge_enabled(), sbinfo comes from an inode
> 
> And the only caller of is_huge_enabled() is shmem_getattr(), with sbinfo
> picked from inode.
> 
> So is there any reason why the hugepage policy can't be per-file, with
> the current being overridable default?

Re: [PATCHv2 2/3] i915: convert to new mount API

[Christoph Hellwig]

On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> Though personally I'm averse to managing "f"objects through
> "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> on the virtual address of a mapping, but the huge-or-not alignment of
> that mapping must have been decided previously).  In Google we do use
> fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> one day I'll get to upstreaming those.

Such an interface seems very useful, although the two fcntls seem a bit
odd.

But I think the point here is that the i915 has its own somewhat odd
instance of tmpfs.  If we could pass the equivalent of the huge=*
options to shmem_file_setup all that garbage (including the
shmem_file_setup_with_mnt function) could go away.

Re: [PATCHv2 2/3] i915: convert to new mount API

[Christoph Hellwig]

On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> Though personally I'm averse to managing "f"objects through
> "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> on the virtual address of a mapping, but the huge-or-not alignment of
> that mapping must have been decided previously).  In Google we do use
> fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> one day I'll get to upstreaming those.

Such an interface seems very useful, although the two fcntls seem a bit
odd.

But I think the point here is that the i915 has its own somewhat odd
instance of tmpfs.  If we could pass the equivalent of the huge=*
options to shmem_file_setup all that garbage (including the
shmem_file_setup_with_mnt function) could go away.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCHv2 2/3] i915: convert to new mount API

[Al Viro]

On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:

> that mapping must have been decided previously).  In Google we do use
> fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> one day I'll get to upstreaming those.

That'd be nice - we could kill the i915 wierd private shmem instance,
along with some kludges in mm/shmem.c.

Re: [PATCHv2 2/3] i915: convert to new mount API

[Al Viro]

On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:

> that mapping must have been decided previously).  In Google we do use
> fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> one day I'll get to upstreaming those.

That'd be nice - we could kill the i915 wierd private shmem instance,
along with some kludges in mm/shmem.c.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCHv2 2/3] i915: convert to new mount API

[Al Viro]

On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > Though personally I'm averse to managing "f"objects through
> > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > on the virtual address of a mapping, but the huge-or-not alignment of
> > that mapping must have been decided previously).  In Google we do use
> > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> > one day I'll get to upstreaming those.
> 
> Such an interface seems very useful, although the two fcntls seem a bit
> odd.
> 
> But I think the point here is that the i915 has its own somewhat odd
> instance of tmpfs.  If we could pass the equivalent of the huge=*
> options to shmem_file_setup all that garbage (including the
> shmem_file_setup_with_mnt function) could go away.

... or follow shmem_file_super() with whatever that fcntl maps to
internally.  I would really love to get rid of that i915 kludge.

Re: [PATCHv2 2/3] i915: convert to new mount API

[Al Viro]

On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > Though personally I'm averse to managing "f"objects through
> > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > on the virtual address of a mapping, but the huge-or-not alignment of
> > that mapping must have been decided previously).  In Google we do use
> > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> > one day I'll get to upstreaming those.
> 
> Such an interface seems very useful, although the two fcntls seem a bit
> odd.
> 
> But I think the point here is that the i915 has its own somewhat odd
> instance of tmpfs.  If we could pass the equivalent of the huge=*
> options to shmem_file_setup all that garbage (including the
> shmem_file_setup_with_mnt function) could go away.

... or follow shmem_file_super() with whatever that fcntl maps to
internally.  I would really love to get rid of that i915 kludge.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCHv2 2/3] i915: convert to new mount API

[Hugh Dickins]

On Thu, 8 Aug 2019, Al Viro wrote:
> On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > Though personally I'm averse to managing "f"objects through
> > > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > > on the virtual address of a mapping, but the huge-or-not alignment of
> > > that mapping must have been decided previously).  In Google we do use
> > > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> > > one day I'll get to upstreaming those.
> > 
> > Such an interface seems very useful, although the two fcntls seem a bit
> > odd.
> > 
> > But I think the point here is that the i915 has its own somewhat odd
> > instance of tmpfs.  If we could pass the equivalent of the huge=*
> > options to shmem_file_setup all that garbage (including the
> > shmem_file_setup_with_mnt function) could go away.
> 
> ... or follow shmem_file_super() with whatever that fcntl maps to
> internally.  I would really love to get rid of that i915 kludge.

As to the immediate problem of i915_gemfs using remount_fs on linux-next,
IIUC, all that is necessary at the moment is the deletions patch below
(but I'd prefer that to come from the i915 folks).  Since gemfs has no
need to change the huge option from its default to its default.

As to the future of when they get back to wanting huge pages in gemfs,
yes, that can probably best be arranged by using the internals of an
fcntl F_HUGEPAGE on those objects that would benefit from it.

Though my intention there was that the "huge=never" default ought
to continue to refuse to give huge pages, even when asked by fcntl.
So a little hackery may still be required, to allow the i915_gemfs
internal mount to get huge pages when a user mount would not.

As to whether shmem_file_setup_with_mnt() needs to live: I've given
that no thought, but accept that shm_mnt is such a ragbag of different
usages, that i915 is right to prefer their own separate gemfs mount.

Hugh

--- mmotm/drivers/gpu/drm/i915/gem/i915_gemfs.c	2019-07-21 19:40:16.573703780 -0700
+++ linux/drivers/gpu/drm/i915/gem/i915_gemfs.c	2019-08-08 07:19:23.967689058 -0700
@@ -24,28 +24,6 @@ int i915_gemfs_init(struct drm_i915_priv
 	if (IS_ERR(gemfs))
 		return PTR_ERR(gemfs);
 
-	/*
-	 * Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
-	 * likely 2M. Note that within_size may overallocate huge-pages, if say
-	 * we allocate an object of size 2M + 4K, we may get 2M + 2M, but under
-	 * memory pressure shmem should split any huge-pages which can be
-	 * shrunk.
-	 */
-
-	if (has_transparent_hugepage()) {
-		struct super_block *sb = gemfs->mnt_sb;
-		/* FIXME: Disabled until we get W/A for read BW issue. */
-		char options[] = "huge=never";
-		int flags = 0;
-		int err;
-
-		err = sb->s_op->remount_fs(sb, &flags, options);
-		if (err) {
-			kern_unmount(gemfs);
-			return err;
-		}
-	}
-
 	i915->mm.gemfs = gemfs;
 
 	return 0;

Re: [PATCHv2 2/3] i915: convert to new mount API

[Hugh Dickins]

On Thu, 8 Aug 2019, Al Viro wrote:
> On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > Though personally I'm averse to managing "f"objects through
> > > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > > on the virtual address of a mapping, but the huge-or-not alignment of
> > > that mapping must have been decided previously).  In Google we do use
> > > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> > > one day I'll get to upstreaming those.
> > 
> > Such an interface seems very useful, although the two fcntls seem a bit
> > odd.
> > 
> > But I think the point here is that the i915 has its own somewhat odd
> > instance of tmpfs.  If we could pass the equivalent of the huge=*
> > options to shmem_file_setup all that garbage (including the
> > shmem_file_setup_with_mnt function) could go away.
> 
> ... or follow shmem_file_super() with whatever that fcntl maps to
> internally.  I would really love to get rid of that i915 kludge.

As to the immediate problem of i915_gemfs using remount_fs on linux-next,
IIUC, all that is necessary at the moment is the deletions patch below
(but I'd prefer that to come from the i915 folks).  Since gemfs has no
need to change the huge option from its default to its default.

As to the future of when they get back to wanting huge pages in gemfs,
yes, that can probably best be arranged by using the internals of an
fcntl F_HUGEPAGE on those objects that would benefit from it.

Though my intention there was that the "huge=never" default ought
to continue to refuse to give huge pages, even when asked by fcntl.
So a little hackery may still be required, to allow the i915_gemfs
internal mount to get huge pages when a user mount would not.

As to whether shmem_file_setup_with_mnt() needs to live: I've given
that no thought, but accept that shm_mnt is such a ragbag of different
usages, that i915 is right to prefer their own separate gemfs mount.

Hugh

--- mmotm/drivers/gpu/drm/i915/gem/i915_gemfs.c	2019-07-21 19:40:16.573703780 -0700
+++ linux/drivers/gpu/drm/i915/gem/i915_gemfs.c	2019-08-08 07:19:23.967689058 -0700
@@ -24,28 +24,6 @@ int i915_gemfs_init(struct drm_i915_priv
 	if (IS_ERR(gemfs))
 		return PTR_ERR(gemfs);
 
-	/*
-	 * Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
-	 * likely 2M. Note that within_size may overallocate huge-pages, if say
-	 * we allocate an object of size 2M + 4K, we may get 2M + 2M, but under
-	 * memory pressure shmem should split any huge-pages which can be
-	 * shrunk.
-	 */
-
-	if (has_transparent_hugepage()) {
-		struct super_block *sb = gemfs->mnt_sb;
-		/* FIXME: Disabled until we get W/A for read BW issue. */
-		char options[] = "huge=never";
-		int flags = 0;
-		int err;
-
-		err = sb->s_op->remount_fs(sb, &flags, options);
-		if (err) {
-			kern_unmount(gemfs);
-			return err;
-		}
-	}
-
 	i915->mm.gemfs = gemfs;
 
 	return 0;
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCHv2 2/3] i915: convert to new mount API

[Chris Wilson]

Quoting Hugh Dickins (2019-08-08 16:54:16)
> On Thu, 8 Aug 2019, Al Viro wrote:
> > On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > > Though personally I'm averse to managing "f"objects through
> > > > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > > > on the virtual address of a mapping, but the huge-or-not alignment of
> > > > that mapping must have been decided previously).  In Google we do use
> > > > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> > > > one day I'll get to upstreaming those.
> > > 
> > > Such an interface seems very useful, although the two fcntls seem a bit
> > > odd.
> > > 
> > > But I think the point here is that the i915 has its own somewhat odd
> > > instance of tmpfs.  If we could pass the equivalent of the huge=*
> > > options to shmem_file_setup all that garbage (including the
> > > shmem_file_setup_with_mnt function) could go away.
> > 
> > ... or follow shmem_file_super() with whatever that fcntl maps to
> > internally.  I would really love to get rid of that i915 kludge.
> 
> As to the immediate problem of i915_gemfs using remount_fs on linux-next,
> IIUC, all that is necessary at the moment is the deletions patch below
> (but I'd prefer that to come from the i915 folks).  Since gemfs has no
> need to change the huge option from its default to its default.
> 
> As to the future of when they get back to wanting huge pages in gemfs,
> yes, that can probably best be arranged by using the internals of an
> fcntl F_HUGEPAGE on those objects that would benefit from it.
> 
> Though my intention there was that the "huge=never" default ought
> to continue to refuse to give huge pages, even when asked by fcntl.
> So a little hackery may still be required, to allow the i915_gemfs
> internal mount to get huge pages when a user mount would not.
> 
> As to whether shmem_file_setup_with_mnt() needs to live: I've given
> that no thought, but accept that shm_mnt is such a ragbag of different
> usages, that i915 is right to prefer their own separate gemfs mount.
> 
> Hugh
> 
> --- mmotm/drivers/gpu/drm/i915/gem/i915_gemfs.c 2019-07-21 19:40:16.573703780 -0700
> +++ linux/drivers/gpu/drm/i915/gem/i915_gemfs.c 2019-08-08 07:19:23.967689058 -0700
> @@ -24,28 +24,6 @@ int i915_gemfs_init(struct drm_i915_priv
>         if (IS_ERR(gemfs))
>                 return PTR_ERR(gemfs);
>  
> -       /*
> -        * Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
> -        * likely 2M. Note that within_size may overallocate huge-pages, if say
> -        * we allocate an object of size 2M + 4K, we may get 2M + 2M, but under
> -        * memory pressure shmem should split any huge-pages which can be
> -        * shrunk.
> -        */
> -
> -       if (has_transparent_hugepage()) {
> -               struct super_block *sb = gemfs->mnt_sb;
> -               /* FIXME: Disabled until we get W/A for read BW issue. */
> -               char options[] = "huge=never";
> -               int flags = 0;
> -               int err;
> -
> -               err = sb->s_op->remount_fs(sb, &flags, options);
> -               if (err) {
> -                       kern_unmount(gemfs);
> -                       return err;
> -               }
> -       }

That's perfectly fine; we should probably leave a hint as to why gemfs
exists and include the suggestion of looking at per-file hugepage
controls.

Matthew, how does this affect your current plans? If at all?
-Chris

Re: [PATCHv2 2/3] i915: convert to new mount API

[Chris Wilson]

Quoting Hugh Dickins (2019-08-08 16:54:16)
> On Thu, 8 Aug 2019, Al Viro wrote:
> > On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > > Though personally I'm averse to managing "f"objects through
> > > > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
> > > > on the virtual address of a mapping, but the huge-or-not alignment of
> > > > that mapping must have been decided previously).  In Google we do use
> > > > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
> > > > one day I'll get to upstreaming those.
> > > 
> > > Such an interface seems very useful, although the two fcntls seem a bit
> > > odd.
> > > 
> > > But I think the point here is that the i915 has its own somewhat odd
> > > instance of tmpfs.  If we could pass the equivalent of the huge=*
> > > options to shmem_file_setup all that garbage (including the
> > > shmem_file_setup_with_mnt function) could go away.
> > 
> > ... or follow shmem_file_super() with whatever that fcntl maps to
> > internally.  I would really love to get rid of that i915 kludge.
> 
> As to the immediate problem of i915_gemfs using remount_fs on linux-next,
> IIUC, all that is necessary at the moment is the deletions patch below
> (but I'd prefer that to come from the i915 folks).  Since gemfs has no
> need to change the huge option from its default to its default.
> 
> As to the future of when they get back to wanting huge pages in gemfs,
> yes, that can probably best be arranged by using the internals of an
> fcntl F_HUGEPAGE on those objects that would benefit from it.
> 
> Though my intention there was that the "huge=never" default ought
> to continue to refuse to give huge pages, even when asked by fcntl.
> So a little hackery may still be required, to allow the i915_gemfs
> internal mount to get huge pages when a user mount would not.
> 
> As to whether shmem_file_setup_with_mnt() needs to live: I've given
> that no thought, but accept that shm_mnt is such a ragbag of different
> usages, that i915 is right to prefer their own separate gemfs mount.
> 
> Hugh
> 
> --- mmotm/drivers/gpu/drm/i915/gem/i915_gemfs.c 2019-07-21 19:40:16.573703780 -0700
> +++ linux/drivers/gpu/drm/i915/gem/i915_gemfs.c 2019-08-08 07:19:23.967689058 -0700
> @@ -24,28 +24,6 @@ int i915_gemfs_init(struct drm_i915_priv
>         if (IS_ERR(gemfs))
>                 return PTR_ERR(gemfs);
>  
> -       /*
> -        * Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
> -        * likely 2M. Note that within_size may overallocate huge-pages, if say
> -        * we allocate an object of size 2M + 4K, we may get 2M + 2M, but under
> -        * memory pressure shmem should split any huge-pages which can be
> -        * shrunk.
> -        */
> -
> -       if (has_transparent_hugepage()) {
> -               struct super_block *sb = gemfs->mnt_sb;
> -               /* FIXME: Disabled until we get W/A for read BW issue. */
> -               char options[] = "huge=never";
> -               int flags = 0;
> -               int err;
> -
> -               err = sb->s_op->remount_fs(sb, &flags, options);
> -               if (err) {
> -                       kern_unmount(gemfs);
> -                       return err;
> -               }
> -       }

That's perfectly fine; we should probably leave a hint as to why gemfs
exists and include the suggestion of looking at per-file hugepage
controls.

Matthew, how does this affect your current plans? If at all?
-Chris

Re: [PATCHv2 2/3] i915: convert to new mount API

[Matthew Auld]

On 08/08/2019 17:23, Chris Wilson wrote:
> Quoting Hugh Dickins (2019-08-08 16:54:16)
>> On Thu, 8 Aug 2019, Al Viro wrote:
>>> On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
>>>> On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
>>>>> Though personally I'm averse to managing "f"objects through
>>>>> "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works
>>>>> on the virtual address of a mapping, but the huge-or-not alignment of
>>>>> that mapping must have been decided previously).  In Google we do use
>>>>> fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis -
>>>>> one day I'll get to upstreaming those.
>>>>
>>>> Such an interface seems very useful, although the two fcntls seem a bit
>>>> odd.
>>>>
>>>> But I think the point here is that the i915 has its own somewhat odd
>>>> instance of tmpfs.  If we could pass the equivalent of the huge=*
>>>> options to shmem_file_setup all that garbage (including the
>>>> shmem_file_setup_with_mnt function) could go away.
>>>
>>> ... or follow shmem_file_super() with whatever that fcntl maps to
>>> internally.  I would really love to get rid of that i915 kludge.
>>
>> As to the immediate problem of i915_gemfs using remount_fs on linux-next,
>> IIUC, all that is necessary at the moment is the deletions patch below
>> (but I'd prefer that to come from the i915 folks).  Since gemfs has no
>> need to change the huge option from its default to its default.
>>
>> As to the future of when they get back to wanting huge pages in gemfs,
>> yes, that can probably best be arranged by using the internals of an
>> fcntl F_HUGEPAGE on those objects that would benefit from it.
>>
>> Though my intention there was that the "huge=never" default ought
>> to continue to refuse to give huge pages, even when asked by fcntl.
>> So a little hackery may still be required, to allow the i915_gemfs
>> internal mount to get huge pages when a user mount would not.
>>
>> As to whether shmem_file_setup_with_mnt() needs to live: I've given
>> that no thought, but accept that shm_mnt is such a ragbag of different
>> usages, that i915 is right to prefer their own separate gemfs mount.
>>
>> Hugh
>>
>> --- mmotm/drivers/gpu/drm/i915/gem/i915_gemfs.c 2019-07-21 19:40:16.573703780 -0700
>> +++ linux/drivers/gpu/drm/i915/gem/i915_gemfs.c 2019-08-08 07:19:23.967689058 -0700
>> @@ -24,28 +24,6 @@ int i915_gemfs_init(struct drm_i915_priv
>>          if (IS_ERR(gemfs))
>>                  return PTR_ERR(gemfs);
>>   
>> -       /*
>> -        * Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
>> -        * likely 2M. Note that within_size may overallocate huge-pages, if say
>> -        * we allocate an object of size 2M + 4K, we may get 2M + 2M, but under
>> -        * memory pressure shmem should split any huge-pages which can be
>> -        * shrunk.
>> -        */
>> -
>> -       if (has_transparent_hugepage()) {
>> -               struct super_block *sb = gemfs->mnt_sb;
>> -               /* FIXME: Disabled until we get W/A for read BW issue. */
>> -               char options[] = "huge=never";
>> -               int flags = 0;
>> -               int err;
>> -
>> -               err = sb->s_op->remount_fs(sb, &flags, options);
>> -               if (err) {
>> -                       kern_unmount(gemfs);
>> -                       return err;
>> -               }
>> -       }
> 
> That's perfectly fine; we should probably leave a hint as to why gemfs
> exists and include the suggestion of looking at per-file hugepage
> controls.
> 
> Matthew, how does this affect your current plans? If at all?
Fine with me.

> -Chris
> 

✗ Fi.CI.CHECKPATCH: warning for convert i915 to new mount API (rev2)

[Patchwork]

== Series Details ==

Series: convert i915 to new mount API (rev2)
URL   : https://patchwork.freedesktop.org/series/64720/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e099d8c4e87d fs: export put_filesystem()
fe79bda9adc6 i915: convert to new mount API
-:79: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

total: 1 errors, 0 warnings, 0 checks, 28 lines checked
031da3837c45 i915: do not leak module ref counter

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

✓ Fi.CI.BAT: success for convert i915 to new mount API (rev2)

[Patchwork]

== Series Details ==

Series: convert i915 to new mount API (rev2)
URL   : https://patchwork.freedesktop.org/series/64720/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6657 -> Patchwork_13921
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/

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

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

### IGT changes ###

#### Suppressed ####

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

  * igt@kms_chamelium@vga-hpd-fast:
    - {fi-icl-u4}:        [SKIP][1] ([fdo#109309]) -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-icl-u4/igt@kms_chamelium@vga-hpd-fast.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-icl-u4/igt@kms_chamelium@vga-hpd-fast.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_mmap_gtt@basic-copy:
    - fi-icl-u3:          [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-icl-u3/igt@gem_mmap_gtt@basic-copy.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-icl-u3/igt@gem_mmap_gtt@basic-copy.html

  * igt@i915_selftest@live_execlists:
    - fi-bwr-2160:        [PASS][5] -> [DMESG-WARN][6] ([fdo#111115])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-bwr-2160/igt@i915_selftest@live_execlists.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-bwr-2160/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_hangcheck:
    - fi-bwr-2160:        [PASS][7] -> [DMESG-FAIL][8] ([fdo#111115])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-kbl-7567u:       [PASS][9] -> [WARN][10] ([fdo#109380])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-kbl-7567u/igt@kms_chamelium@common-hpd-after-suspend.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-kbl-7567u/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
    - fi-kbl-7567u:       [PASS][11] -> [SKIP][12] ([fdo#109271]) +23 similar issues
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-kbl-7567u/igt@kms_pipe_crc_basic@read-crc-pipe-c.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-kbl-7567u/igt@kms_pipe_crc_basic@read-crc-pipe-c.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s3:
    - fi-blb-e6850:       [INCOMPLETE][13] ([fdo#107718]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html

  * igt@i915_module_load@reload:
    - fi-icl-u3:          [DMESG-WARN][15] ([fdo#107724]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-icl-u3/igt@i915_module_load@reload.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-icl-u3/igt@i915_module_load@reload.html

  * igt@kms_chamelium@hdmi-edid-read:
    - {fi-icl-u4}:        [FAIL][17] ([fdo#111045] / [fdo#111046 ]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-icl-u4/igt@kms_chamelium@hdmi-edid-read.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-icl-u4/igt@kms_chamelium@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][19] ([fdo#109485]) -> [PASS][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
    - {fi-icl-u4}:        [FAIL][21] ([fdo#111045]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html

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

  [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111046 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111046 
  [fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
  [fdo#111115]: https://bugs.freedesktop.org/show_bug.cgi?id=111115


Participating hosts (55 -> 40)
------------------------------

  Missing    (15): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-icl-y fi-bdw-samus fi-byt-n2820 fi-bsw-kefka fi-kbl-r fi-skl-6600u fi-snb-2600 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6657 -> Patchwork_13921

  CI-20190529: 20190529
  CI_DRM_6657: 00952d067bbbb0342b696191e1f8180ed6abb641 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5125: 35d81d01b1599b4bc4df0e09e25f6f531eed4f8a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13921: 031da3837c454b065136f9d69c55907538a37d29 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

031da3837c45 i915: do not leak module ref counter
fe79bda9adc6 i915: convert to new mount API
e099d8c4e87d fs: export put_filesystem()

== Logs ==

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

✗ Fi.CI.IGT: failure for convert i915 to new mount API (rev2)

[Patchwork]

== Series Details ==

Series: convert i915 to new mount API (rev2)
URL   : https://patchwork.freedesktop.org/series/64720/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6657_full -> Patchwork_13921_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_13921_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_13921_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_13921_full:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_mmap_gtt@big-copy-odd:
    - shard-kbl:          [PASS][1] -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-kbl2/igt@gem_mmap_gtt@big-copy-odd.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-kbl6/igt@gem_mmap_gtt@big-copy-odd.html

  
#### Warnings ####

  * igt@gem_ctx_shared@exec-single-timeline-bsd1:
    - shard-iclb:         [SKIP][3] ([fdo#109276]) -> [FAIL][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb8/igt@gem_ctx_shared@exec-single-timeline-bsd1.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb1/igt@gem_ctx_shared@exec-single-timeline-bsd1.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_schedule@in-order-bsd:
    - shard-iclb:         [PASS][5] -> [SKIP][6] ([fdo#111325])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb5/igt@gem_exec_schedule@in-order-bsd.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb4/igt@gem_exec_schedule@in-order-bsd.html

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#109276]) +18 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb1/igt@gem_exec_schedule@preempt-contexts-bsd2.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb6/igt@gem_exec_schedule@preempt-contexts-bsd2.html

  * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
    - shard-kbl:          [PASS][9] -> [FAIL][10] ([fdo#109660])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-kbl4/igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-kbl2/igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
    - shard-glk:          [PASS][11] -> [FAIL][12] ([fdo#104873])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-glk9/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-glk3/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-glk:          [PASS][13] -> [FAIL][14] ([fdo#102887])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-glk1/igt@kms_flip@flip-vs-expired-vblank.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-glk4/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_flip@modeset-vs-vblank-race:
    - shard-glk:          [PASS][15] -> [FAIL][16] ([fdo#103060])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-glk8/igt@kms_flip@modeset-vs-vblank-race.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-glk1/igt@kms_flip@modeset-vs-vblank-race.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-apl:          [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +5 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-apl3/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-apl6/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render:
    - shard-iclb:         [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [PASS][21] -> [FAIL][22] ([fdo#108145])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb8/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [PASS][25] -> [SKIP][26] ([fdo#109441]) +3 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb8/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@perf@blocking:
    - shard-skl:          [PASS][27] -> [FAIL][28] ([fdo#110728])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-skl6/igt@perf@blocking.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-skl9/igt@perf@blocking.html

  * igt@tools_test@tools_test:
    - shard-hsw:          [PASS][29] -> [SKIP][30] ([fdo#109271])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-hsw7/igt@tools_test@tools_test.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-hsw1/igt@tools_test@tools_test.html

  
#### Possible fixes ####

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [SKIP][31] ([fdo#110854]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb5/igt@gem_exec_balancer@smoke.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb4/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [SKIP][33] ([fdo#111325]) -> [PASS][34] +3 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb6/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd:
    - shard-iclb:         [SKIP][35] -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb4/igt@gem_exec_schedule@preempt-queue-bsd.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb5/igt@gem_exec_schedule@preempt-queue-bsd.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
    - shard-iclb:         [INCOMPLETE][37] ([fdo#107713] / [fdo#108840]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb2/igt@i915_pm_rpm@system-suspend-execbuf.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb8/igt@i915_pm_rpm@system-suspend-execbuf.html

  * igt@i915_pm_rps@reset:
    - shard-skl:          [FAIL][39] ([fdo#102250]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-skl8/igt@i915_pm_rps@reset.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-skl8/igt@i915_pm_rps@reset.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-apl:          [DMESG-WARN][41] ([fdo#108566]) -> [PASS][42] +3 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-apl3/igt@i915_suspend@fence-restore-tiled2untiled.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-apl6/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-kbl:          [DMESG-WARN][43] ([fdo#108566]) -> [PASS][44] +2 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-kbl4/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_cursor_edge_walk@pipe-b-64x64-top-edge:
    - shard-kbl:          [DMESG-WARN][45] ([fdo#111317]) -> [PASS][46] +1 similar issue
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-kbl7/igt@kms_cursor_edge_walk@pipe-b-64x64-top-edge.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-kbl6/igt@kms_cursor_edge_walk@pipe-b-64x64-top-edge.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
    - shard-apl:          [DMESG-WARN][47] -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-apl4/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-apl5/igt@kms_flip@basic-flip-vs-wf_vblank.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
    - shard-iclb:         [FAIL][49] ([fdo#103167]) -> [PASS][50] +6 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
    - shard-iclb:         [INCOMPLETE][51] ([fdo#107713] / [fdo#110036 ]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb4/igt@kms_plane@pixel-format-pipe-a-planes-source-clamping.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb2/igt@kms_plane@pixel-format-pipe-a-planes-source-clamping.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
    - shard-skl:          [INCOMPLETE][53] ([fdo#104108]) -> [PASS][54] +1 similar issue
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-skl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-skl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][55] ([fdo#108145] / [fdo#110403]) -> [PASS][56] +1 similar issue
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [SKIP][57] ([fdo#109441]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb4/igt@kms_psr@psr2_no_drrs.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb2/igt@kms_psr@psr2_no_drrs.html

  * igt@perf@polling:
    - shard-skl:          [FAIL][59] ([fdo#110728]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-skl4/igt@perf@polling.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-skl1/igt@perf@polling.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [SKIP][61] ([fdo#109276]) -> [PASS][62] +12 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb5/igt@prime_vgem@fence-wait-bsd2.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb4/igt@prime_vgem@fence-wait-bsd2.html

  
#### Warnings ####

  * igt@gem_ctx_shared@exec-single-timeline-bsd2:
    - shard-iclb:         [SKIP][63] ([fdo#109276]) -> [FAIL][64] ([fdo#111327])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb7/igt@gem_ctx_shared@exec-single-timeline-bsd2.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb2/igt@gem_ctx_shared@exec-single-timeline-bsd2.html

  * igt@gem_exec_schedule@independent-bsd1:
    - shard-iclb:         [FAIL][65] ([fdo#110946]) -> [SKIP][66] ([fdo#109276])
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb2/igt@gem_exec_schedule@independent-bsd1.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb3/igt@gem_exec_schedule@independent-bsd1.html

  * igt@gem_exec_schedule@independent-bsd2:
    - shard-iclb:         [SKIP][67] ([fdo#109276]) -> [FAIL][68] ([fdo#110946])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb5/igt@gem_exec_schedule@independent-bsd2.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html

  * igt@gem_mocs_settings@mocs-reset-bsd2:
    - shard-iclb:         [SKIP][69] ([fdo#109276]) -> [FAIL][70] ([fdo#111330]) +1 similar issue
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb3/igt@gem_mocs_settings@mocs-reset-bsd2.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb1/igt@gem_mocs_settings@mocs-reset-bsd2.html

  * igt@gem_mocs_settings@mocs-settings-bsd2:
    - shard-iclb:         [FAIL][71] -> [SKIP][72] ([fdo#109276])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6657/shard-iclb4/igt@gem_mocs_settings@mocs-settings-bsd2.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13921/shard-iclb5/igt@gem_mocs_settings@mocs-settings-bsd2.html

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

  [fdo#102250]: https://bugs.freedesktop.org/show_bug.cgi?id=102250
  [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
  [fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#109660]: https://bugs.freedesktop.org/show_bug.cgi?id=109660
  [fdo#110036 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110036 
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#110728]: https://bugs.freedesktop.org/show_bug.cgi?id=110728
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#110946]: https://bugs.freedesktop.org/show_bug.cgi?id=110946
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111317]: https://bugs.freedesktop.org/show_bug.cgi?id=111317
  [fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325
  [fdo#111327]: https://bugs.freedesktop.org/show_bug.cgi?id=111327
  [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6657 -> Patchwork_13921

  CI-20190529: 20190529
  CI_DRM_6657: 00952d067bbbb0342b696191e1f8180ed6abb641 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5125: 35d81d01b1599b4bc4df0e09e25f6f531eed4f8a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13921: 031da3837c454b065136f9d69c55907538a37d29 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

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