[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()

[Dave Gordon]

On 28/04/16 18:48, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
> URL   : https://patchwork.freedesktop.org/series/6491/
> State : warning
>
> == Summary ==
>
> Series 6491v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/6491/revisions/1/mbox/
>
> Test gem_busy:
>          Subgroup basic-blt:
>                  pass       -> DMESG-WARN (bsw-nuc-2)
>                  pass       -> DMESG-WARN (skl-nuci5)
>                  pass       -> DMESG-WARN (bdw-nuci7-2)
>                  pass       -> DMESG-WARN (ivb-t430s)
>                  pass       -> DMESG-WARN (bdw-ultra)
>                  pass       -> DMESG-WARN (skl-i7k-2)
>                  pass       -> DMESG-WARN (byt-nuc)
>                  pass       -> DMESG-WARN (snb-x220t)
>                  pass       -> DMESG-WARN (hsw-brixbox)

Well, that's as expected: it's hitting the WARN_ON() that I put in there 
to check on usage of obj->dirty vs. pages_pin_count. Stack traces are 
all the same, like this one:

[   72.459223] ------------[ cut here ]------------
[   72.459254] WARNING: CPU: 0 PID: 6012 at 
drivers/gpu/drm/i915/i915_drv.h:3027 
i915_gem_object_set_to_gtt_domain+0x21c/0x280 [i915]
[   72.459255] WARN_ON(obj->pages_pin_count == 0)
[   72.459256] Modules linked in:
[   72.459257]  snd_hda_codec_hdmi snd_hda_intel i915 
x86_pkg_temp_thermal snd_hda_codec snd_hwdep snd_hda_core 
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul mei_me lpc_ich 
ghash_clmulni_intel mei snd_pcm r8169 mii
[   72.459266] CPU: 0 PID: 6012 Comm: gem_busy Tainted: G        W 
  4.6.0-rc5-CI-Patchwork_2105+ #1
[   72.459267] Hardware name: Gigabyte Technology Co., Ltd. 
H87M-D3H/H87M-D3H, BIOS F11 08/18/2015
[   72.459268]  0000000000000000 ffff880212053c80 ffffffff8140de35 
ffff880212053cd0
[   72.459270]  0000000000000000 ffff880212053cc0 ffffffff81079c8c 
00000bd312e5a980
[   72.459272]  ffff880212e5a980 0000000000000001 ffff8800d7c70000 
0000000000000000
[   72.459274] Call Trace:
[   72.459277]  [<ffffffff8140de35>] dump_stack+0x67/0x92
[   72.459280]  [<ffffffff81079c8c>] __warn+0xcc/0xf0
[   72.459281]  [<ffffffff81079cfa>] warn_slowpath_fmt+0x4a/0x50
[   72.459293]  [<ffffffffa01efacb>] ? 
i915_gem_object_flush_cpu_write_domain.part.47+0x14b/0x1b0 [i915]
[   72.459303]  [<ffffffffa01f113c>] 
i915_gem_object_set_to_gtt_domain+0x21c/0x280 [i915]
[   72.459313]  [<ffffffffa01f128e>] 
i915_gem_set_domain_ioctl+0xee/0x160 [i915]
[   72.459315]  [<ffffffff815282ed>] drm_ioctl+0x13d/0x590
[   72.459325]  [<ffffffffa01f11a0>] ? 
i915_gem_object_set_to_gtt_domain+0x280/0x280 [i915]
[   72.459327]  [<ffffffff81199ba7>] ? handle_mm_fault+0x47/0x1e90
[   72.459329]  [<ffffffff811ee38a>] do_vfs_ioctl+0x8a/0x670
[   72.459331]  [<ffffffff811fa21a>] ? __fget_light+0x6a/0x90
[   72.459332]  [<ffffffff811ee9ac>] SyS_ioctl+0x3c/0x70
[   72.459333]  [<ffffffff817dc7a9>] entry_SYSCALL_64_fastpath+0x1c/0xac
[   72.459334] ---[ end trace 156adc997a22f992 ]---

So, is that a bug, marking an object dirty when pages_pin_count is 0? 
Does that mean that a program can set a BO to the GTT domain (or the CPU 
domain?), update its contents, and then it gets paged out due to memory 
pressure and the updates are lost?

Or ... no, I think the problem scenario would be
* set to GTT => mark dirty
* BO paged out => flushed to swap, marked clean
* BO paged in => still clean
* update contents => still clean?
* get paged out => not written out?

Or are we guaranteed to hit another mark_dirty during the process of 
updating the contents of the paged-in buffer?

.Dave.