linux-kernel - Re: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is calculated

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <23d45518-3565-e915-c6d4-45dabe82ea4c@suse.de>
Date:   Mon, 17 Apr 2023 10:15:59 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Pierre Asselin <pa@...ix.com>
Cc:     jfalempe@...hat.com, daniel.vetter@...ll.ch, javierm@...hat.com,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        hdegoede@...hat.com, ardb@...nel.org
Subject: Re: [PATCH] firmware/sysfb: Fix wrong stride when bits-per-pixel is
 calculated

Hi,

thanks a lot to both of you for this bug fix.

Am 13.04.23 um 03:34 schrieb Pierre Asselin:
>> (not tested)
> 
> Tested.  It fixes the regression on my laptop.
> 
>> diff --git a/drivers/firmware/sysfb_simplefb.c
>> b/drivers/firmware/sysfb_simplefb.c
>> index 82c64cb9f531..9f5299d54732 100644
>> --- a/drivers/firmware/sysfb_simplefb.c
>> +++ b/drivers/firmware/sysfb_simplefb.c
>> @@ -56,10 +56,11 @@ __init bool sysfb_parse_mode(const struct screen_info
>> *si,
>>   	 * don't specify alpha channels.
>>   	 */
>>   	if (si->lfb_depth > 8) {
>> -		bits_per_pixel = max(max3(si->red_size + si->red_pos,
>> +		bits_per_pixel = max3(max3(si->red_size + si->red_pos,
>>   					  si->green_size + si->green_pos,
>>   					  si->blue_size + si->blue_pos),
>> -				     si->rsvd_size + si->rsvd_pos);
>> +				     si->rsvd_size + si->rsvd_pos,
>> +				     si->lfb_depth);

I'm OK with this change. There's a comment

  "The best solution is to compute bits_per_pixel here and ignore 
lfb_depth."

I'd change this to

  "The best solution is to compute bits_per_pixel here from the color 
bits, the reserved bits and the reported color depth; whatever is highest."

That will hopefully clarify the meaning of these max3() statements. They 
are not obvious at first.

Best regards
Thomas


>>   	} else {
>>   		bits_per_pixel = si->lfb_depth;
>>   	}
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)