From: Jani Nikula <jani.nikula@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/edid: fix invalid EDID extension block filtering
Date: Thu, 31 Mar 2022 13:06:03 +0300 [thread overview]
Message-ID: <87r16ia12s.fsf@intel.com> (raw)
In-Reply-To: <YkSQBaW8swA7LY9M@intel.com>
On Wed, 30 Mar 2022, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Mar 30, 2022 at 08:04:26PM +0300, Jani Nikula wrote:
>> The invalid EDID block filtering uses the number of valid EDID
>> extensions instead of all EDID extensions for looping the extensions in
>> the copy. This is fine, by coincidence, if all the invalid blocks are at
>> the end of the EDID. However, it's completely broken if there are
>> invalid extensions in the middle; the invalid blocks are included and
>> valid blocks are excluded.
>>
>> Fix it by modifying the base block after, not before, the copy.
>>
>> Fixes: 14544d0937bf ("drm/edid: Only print the bad edid when aborting")
>> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Thanks, pushed to drm-misc-next. I didn't bother with -fixes, because
the bug is ancient and rare, and that would only cause conflicts for me.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/drm_edid.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index d79b06f7f34c..8829120470ab 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2031,9 +2031,6 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
>>
>> connector_bad_edid(connector, edid, edid[0x7e] + 1);
>>
>> - edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
>> - edid[0x7e] = valid_extensions;
>> -
>> new = kmalloc_array(valid_extensions + 1, EDID_LENGTH,
>> GFP_KERNEL);
>> if (!new)
>> @@ -2050,6 +2047,9 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
>> base += EDID_LENGTH;
>> }
>>
>> + new[EDID_LENGTH - 1] += new[0x7e] - valid_extensions;
>> + new[0x7e] = valid_extensions;
>> +
>> kfree(edid);
>> edid = new;
>> }
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/edid: fix invalid EDID extension block filtering
Date: Thu, 31 Mar 2022 13:06:03 +0300 [thread overview]
Message-ID: <87r16ia12s.fsf@intel.com> (raw)
In-Reply-To: <YkSQBaW8swA7LY9M@intel.com>
On Wed, 30 Mar 2022, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Wed, Mar 30, 2022 at 08:04:26PM +0300, Jani Nikula wrote:
>> The invalid EDID block filtering uses the number of valid EDID
>> extensions instead of all EDID extensions for looping the extensions in
>> the copy. This is fine, by coincidence, if all the invalid blocks are at
>> the end of the EDID. However, it's completely broken if there are
>> invalid extensions in the middle; the invalid blocks are included and
>> valid blocks are excluded.
>>
>> Fix it by modifying the base block after, not before, the copy.
>>
>> Fixes: 14544d0937bf ("drm/edid: Only print the bad edid when aborting")
>> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Thanks, pushed to drm-misc-next. I didn't bother with -fixes, because
the bug is ancient and rare, and that would only cause conflicts for me.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/drm_edid.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index d79b06f7f34c..8829120470ab 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2031,9 +2031,6 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
>>
>> connector_bad_edid(connector, edid, edid[0x7e] + 1);
>>
>> - edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
>> - edid[0x7e] = valid_extensions;
>> -
>> new = kmalloc_array(valid_extensions + 1, EDID_LENGTH,
>> GFP_KERNEL);
>> if (!new)
>> @@ -2050,6 +2047,9 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
>> base += EDID_LENGTH;
>> }
>>
>> + new[EDID_LENGTH - 1] += new[0x7e] - valid_extensions;
>> + new[0x7e] = valid_extensions;
>> +
>> kfree(edid);
>> edid = new;
>> }
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-03-31 10:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 17:04 [Intel-gfx] [PATCH] drm/edid: fix invalid EDID extension block filtering Jani Nikula
2022-03-30 17:04 ` Jani Nikula
2022-03-30 17:14 ` [Intel-gfx] " Ville Syrjälä
2022-03-30 17:14 ` Ville Syrjälä
2022-03-31 10:06 ` Jani Nikula [this message]
2022-03-31 10:06 ` Jani Nikula
2022-03-30 18:03 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for " Patchwork
2022-03-30 18:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-30 22:14 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r16ia12s.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.