Re: [PATCH 0/2] drm/i915: fix rb-tree/llist/list confusion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi,

On 21/09/2023 07:24, Mathias Krause wrote:
On 05.09.23 13:39, Mathias Krause wrote:
Commit 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine
map") introduced a bug regarding engine iteration in default_engines()
as the rb tree isn't set up yet that early during driver initialization.
This triggered a sanity check we have in our grsecurity kernels, fixed
by reverting the offending commit (patch 1) and giving the
type-multiplexed members some more visibility to avoid making a similar
mistake again in the future (patch 2).

Please apply!

Thanks,
Mathias

Mathias Krause (2):
   Revert "drm/i915: Use uabi engines for the default engine map"
   drm/i915: Clarify type evolution of uabi_node/uabi_engines

  drivers/gpu/drm/i915/gem/i915_gem_context.c  |  9 +++++----
  drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +++++++++-
  drivers/gpu/drm/i915/gt/intel_engine_user.c  | 17 +++++++----------
  drivers/gpu/drm/i915/i915_drv.h              | 17 ++++++++++++++++-
  4 files changed, 37 insertions(+), 16 deletions(-)


Ping. Any objections to this series?

Apologies for the delay in getting back to you, I was away from work for a bit.

Tricky thing you discovered and a great analysis in the commit text.

But we cannot simply revert 1ec23ed7126e since that would miss to include the media tile engines on Meteorlake.

What I think should work is to move the call to intel_engines_driver_register() from i915_gem_driver_register() to i915_gem_init(). I can double-check and send a patch, or you can, keeping parts of your great commit message in 1/2?

That would align the expectations of intel_display_driver_probe() which expects GEM to be fully initialized by the time it runs.

2/2 looks good and I would be happy to merge it in the interim. Going forward I would pencil in looking into removing the rbtree and multi-stage complications. Former I think isn't needed, code which needs fast random lookup via the tree never materialized, and latter perhaps could be sorted in place somehow, that is, without the need for two list types externally visible.

Regards,

Tvrtko



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux