linux-kernel - Re: [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci

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: <c4f8ffde-2226-cc1f-a5a8-d7462b92cb24@suse.de>
Date:   Thu, 12 Jan 2023 13:15:48 +0100
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     DRI Development <dri-devel@...ts.freedesktop.org>,
        Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [PATCH 02/11] drm/gma500: Use
 drm_aperture_remove_conflicting_pci_framebuffers

Hi

Am 12.01.23 um 11:45 schrieb Daniel Vetter:
> On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 12.01.23 um 10:59 schrieb Daniel Vetter:
>>> On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote:
>>>> Hi
>>>>
>>>> Am 11.01.23 um 16:41 schrieb Daniel Vetter:
>>>>> This one nukes all framebuffers, which is a bit much. In reality
>>>>> gma500 is igpu and never shipped with anything discrete, so there should
>>>>> not be any difference.
>>>>>
>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@...el.com>
>>>>> ---
>>>>>     drivers/gpu/drm/gma500/psb_drv.c | 2 +-
>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
>>>>> index cd9c73f5a64a..9b0daf90dc50 100644
>>>>> --- a/drivers/gpu/drm/gma500/psb_drv.c
>>>>> +++ b/drivers/gpu/drm/gma500/psb_drv.c
>>>>> @@ -429,7 +429,7 @@ static int psb_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>>>>>     	 * TODO: Refactor psb_driver_load() to map vdc_reg earlier. Then we
>>>>>     	 *       might be able to read the framebuffer range from the device.
>>>>>     	 */
>>>>> -	ret = drm_aperture_remove_framebuffers(true, &driver);
>>>>> +	ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &driver);
>>>>
>>>> This does not work. The comment just above the changed line explains why.
>>>> The device uses shared memory similar to other integrated Intel chips. The
>>>> console is somewhere in a 16 MiB range, which has been stolen by the BIOS
>>>> from main memory. There's only a 1 MiB memory range on the device to program
>>>> the device. Unless you want to refactor as described, this call has to cover
>>>> the whole memory for now.
>>>
>>> Uh. So it's maybe not so pretty, but what if I just call both functions?
>>
>> That's ways more ugly IMHO.
>>
>>> That way we get the vga handling through the pci one, and the "make sure
>>> there's no fb left" through the other one. Plus comment of course.
>>>
>>> Otherwise we'd need to somehow keep the vga stuff in the non-pci paths,
>>> and that just feels all kinds of wrong to me.
>>
>> With your patch applied, aperture_detach_devices() does all the work of
>> removing. I'd add the following internal functions:
>>
>> static void aperture_detach_head(bool is_primary)
>> {
>> 	/*
>> 	 * lengthy comment here
>> 	 */
>> 	if (is_primary)
>> 		sysfb_disable()
>> }
>>
>> static void aperture_detach_tail(bool remove_vga)
>> {
>> 	if (remove_vga) {
>> 		aperture_detach_devices(VGA_PHYS_)
>> 		vga_remove_vgacon()
>> 	}
>> }
>>
>> And call both of them at the beginning/end of
>> aperture_remove_conflicting_devices() and
>> aperture_remove_conflicting_pci_devices().
>>
>> You'd still need to primary argument to
>> aperture_remove_conflicting_devices(), but there will be no code duplication
>> with the aperture helpers and the purpose of each code fragment will be
>> clearer.
> 
> Yeah I don't want the primary argument. Aside from this one case here it's
> not needed. Also by pushing this special case into the one driver that
> needs it we keep it contained, instead of spreading it all around.
> Inflicting a parameter on every (and in total we have a lot of callers of
> this stuff) just because of gma500 does not seem like a good idea to me.

Unfortunately, vgacon and vgaarb require a PCI device. I don't like the 
proposal, but maybe it's the best for now. So go ahead if you like. I do 
expect that this needs additional work in future, however.

Just some more thoughts.

Grep for drm_aperture_remove_framebuffers(). Within DRM there are really 
just 10 drivers calling this function (vs. 12 callers of 
drm_aperture_remove_conflicting_pci_framebuffers()). In fbdev, there are 
many callers of the PCI helper (~40) and apparently only 3 for the 
non-PCI one. The other drivers are panels, USB, MIPI, etc and don't 
interact with the system framebuffer. Compared to the overall number of 
drivers, we have surprisingly few 'traditional graphics cards' in DRM.

Another thing is that gma500 and the other 9 drivers simply don't bother 
to get the framebuffer range. They should be reworked to fetch the 
configured framebuffer from the device and release that region only. The 
practical impact is close to zero, so it hasn't happened.

Best regards
Thomas


> -Daniel

-- 
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)