linux-kernel - Re: [PATCH 2/3] fbdev/simplefb: Cleanup fb_info in .fb

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: <e1797321-d901-45dc-713f-7f706147c341@suse.de>
Date:   Thu, 5 May 2022 10:49:36 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Javier Martinez Canillas <javierm@...hat.com>,
        linux-kernel@...r.kernel.org
Cc:     Daniel Vetter <daniel.vetter@...ll.ch>,
        linux-fbdev@...r.kernel.org, Helge Deller <deller@....de>,
        dri-devel@...ts.freedesktop.org,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH 2/3] fbdev/simplefb: Cleanup fb_info in .fb_destroy rather
 than .remove

Hi

Am 05.05.22 um 10:28 schrieb Javier Martinez Canillas:
> Hello Thomas,
> 
> On 5/5/22 10:05, Thomas Zimmermann wrote:
> 
> [snip]
> 
>>>
>>> In other words, in most cases (i.e: only fbcon bound to the fbdev)
>>> the driver's removal/ device unbind and the memory release will be
>>> at the same time.
>>>
>>
>> We're one the same page here, but it's still sort of a mystery to me why
>> this works in practice.
>>
>> I'm specifically talking about pci_request_regions() in vmwgfx [1]. IIRC
>> this would fail if simplefb still owns the framebuffer region. Lots of
>> systems run Plymouth during boot and this should result in failures
>> occasionally. Still, we never heard about anything.
>>
> 
> Yes, I think is because Plymouth IIUC waits for a /dev/dri/card? to be
> present and only uses a /dev/fb? as a fallback if a timeout expires.

Oh, right! The infamous plymouth timeout. 'sleep(30)' is the swiss-army 
knife of concurrent programming. ;)

But I'm not blaming anyone. There are situations where nothing else 
helps. Plymouth really can't do anything else here. We've received 
reports for gfx-handover bugs when the timeout expired and plymouth uses 
the fbdev. The system got stuck then because of fbdev IIRC.

Best regards
Thomas

> 
> At least in Fedora (even before the efifb -> simpledrm change) it will
> use KMS/DRM since the DRM kernel module for the graphics device in the
> machine would be in the intird.
> 
> So efifb was only used for fbcon and plymouth would only use DRM/KMS
> and not its fbdev backend.
> 
> This seems to be sort of a corner case when you have {efi,simple}fb
> in the early boot but the real DRM module only in the rootfs after the
> initrd has done a pivot_root(2).
>   
>> Of course, it's always been broken (even long before real fbdev
>> hotunplugging). Switching to simpledrm resolves the problem.
>>
> 
> Indeed. My opinion after dealing with these fbdev problems is that we
> shouldn't try to fix all possible corner cases and just try to get rid
> of fbdev as soon as possible.
>   --
> Best regards,
> 
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
> 

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