[Intel-gfx] [PATCH] drm/i915: Don't try to check max stride for disabled/non-existent display

[Matt Roper]

On Mon, Aug 10, 2020 at 09:53:44PM +0100, Chris Wilson wrote:
> Quoting Matt Roper (2020-08-10 19:08:51)
> > Userspace may still create GEM dumb buffers even on platforms with
> > disabled or non-existent display.  When creating dumb buffers we try to
> > check the max fb stride for the platform by looking at the first pipe on
> > the platform.  We previously fixed a crash related to accessing the
> > non-existent PIPE_A in commit 8ac495f624a4 ("drm/i915: Don't oops in
> > dumb_create ioctl if we have no crtcs") but the crash is back as of
> > commit eae3da27ba84 ("drm/i915: Get first crtc instead of PIPE_A crtc")
> > because we now try to iterate over the [uninitialized] crtc list.
> 
> drm_mode_config_init() is still being called
> i915_driver_probe
>   -> i915_driver_modeset_probe_noirq
>     -> intel_modeset_init_noirq
>       -> intel_mode_config_init
>         -> drm_mode_config_init
> regardless of the status for HAS_DISPLAY or INTEL_DISPLAY_ENABLED. So
> drm_crtc_index(0) should be returning NULL?

Ah, you're right.  The kernel that I was looking at the backtrace from
was a bit different than drm-tip and had a different initialization
flow.  Looks like drm-tip doesn't suffer from the same problem and we
don't need this patch after all.


Matt

> -Chris

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795