[Intel-gfx] [PATCH 2/3] drm/i915/sdvo: Robustify the dtd<->drm_mode conversions

[Daniel Vetter]

On Tue, Sep 10, 2013 at 12:26 PM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
>>  static void intel_sdvo_get_mode_from_dtd(struct drm_display_mode * mode,
>>                                        const struct intel_sdvo_dtd *dtd)
>>  {
>> +     memset(mode, 0, sizeof(*mode));
>
> I have a theoretical worry that someone might end up calling this on a
> mode that sits on some list or was actually allocated and has a proper
> object id which we'd leak here.
>
> To make it totally safe you could populate a pristine mode struct and
> use drm_mode_copy() to overwrite adjusted_mode. Assuming we're not so
> short on stack space that our oversized mode struct would cause issues.
> Other options would be to add some WARNs to catch wrongdoers, or embed
> a temp mode for this purpose inside the intel_sdvo struct.

We can't really check for this since list_empty on stack garbage won't
work too well, either. And e.g. ->get_config has the pipe config on
the stack. So I think we just need to do review here. I also think the
risk is pretty low, this is all used in internal structures around
pipe_config, where the mode is never linked.

>> +
>>       mode->hdisplay = dtd->part1.h_active;
>>       mode->hdisplay += ((dtd->part1.h_high >> 4) & 0x0f) << 8;
>>       mode->hsync_start = mode->hdisplay + dtd->part2.h_sync_off;
>> @@ -872,6 +874,8 @@ static void intel_sdvo_get_mode_from_dtd(struct drm_display_mode * mode,
>
> Somewhere around these parts we have:
>
> 'mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);'
>
> It can now be eliminated.

Will fix and resend.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch