[Bug 106008] [CI] igt at kms_rmfb@(close-fd|rmfb-ioctl) - fail - Failed assertion: planeres->fb_id == 0

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106008

--- Comment #2 from Arek Hiler <arkadiusz.hiler at intel.com> ---
Seem like on pre-ILK rmfb does not behave like it should.

The test looks correct and does what it advertises:
/*
 * 1. Set primary plane to a known fb.
 * 2. Make sure getcrtc returns the correct fb id.
 * 3. Call rmfb on the fb.
 * 4. Make sure getcrtc returns 0 fb id.
 *
 * RMFB is supposed to free the framebuffers from any and all planes,
 * so test this and make sure it works.
 */

The first thing that can go wrong is race condition - freeing frambuffers from
the planes is a deferred task:
  /*
   * we now own the reference that was stored in the fbs list
   *
   * drm_framebuffer_remove may fail with -EINTR on pending signals,
   * so run this in a separate stack as there's no way to correctly
   * handle this after the fb is already removed from the lookup table.
   */
  struct drm_mode_rmfb_work arg;

  INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
  INIT_LIST_HEAD(&arg.fbs);
  list_add_tail(&fb->filp_head, &arg.fbs);

  schedule_work(&arg.work);
  flush_work(&arg.work);
  destroy_work_on_stack(&arg.work);

But there are also two paths there - for atomic and legacy removing of fb:
  if (drm_drv_uses_atomic_modeset(dev)) {
        int ret = atomic_remove_fb(fb);
        WARN(ret, "atomic remove_fb failed with %i\n", ret);
  } else
        legacy_remove_fb(fb);
  }

And the offending machines seem to exactly match the legacy path:
  /* Disable nuclear pageflip by default on pre-ILK */
  if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
        dev_priv->drm.driver_features &= ~DRIVER_ATOMIC;


The code on the legacy path looks correct though, and the main difference seem
to be:
drm_modeset_lock_all(dev);

Which may take time to acquire and it's actually combination of the two
possible issues from above.


Possible user impact in worst case: memory leak when using rmfb for pre-atomic
platforms, but quite likely it's not that and there were no reports of this in
the wild. Keeping the priority as "medium".

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190823/75b57a63/attachment-0001.html>