linux-kernel - Re: [PATCH 00/12] Recover sysfb after DRM probe failure

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: <CABQX2QMn_dTh2h44LRwB7+RxGqK3Jn+QCx38xWrzpNJG5SZ9-Q@mail.gmail.com>
Date: Thu, 15 Jan 2026 22:59:58 -0500
From: Zack Rusin <zack.rusin@...adcom.com>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: dri-devel@...ts.freedesktop.org, Alex Deucher <alexander.deucher@....com>, 
	amd-gfx@...ts.freedesktop.org, Ard Biesheuvel <ardb@...nel.org>, Ce Sun <cesun102@....com>, 
	Chia-I Wu <olvaffe@...il.com>, Christian König <christian.koenig@....com>, 
	Danilo Krummrich <dakr@...nel.org>, Dave Airlie <airlied@...hat.com>, 
	Deepak Rawat <drawat.floss@...il.com>, Dmitry Osipenko <dmitry.osipenko@...labora.com>, 
	Gerd Hoffmann <kraxel@...hat.com>, Gurchetan Singh <gurchetansingh@...omium.org>, 
	Hans de Goede <hansg@...nel.org>, Hawking Zhang <Hawking.Zhang@....com>, Helge Deller <deller@....de>, 
	intel-gfx@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org, 
	Jani Nikula <jani.nikula@...ux.intel.com>, Javier Martinez Canillas <javierm@...hat.com>, 
	Jocelyn Falempe <jfalempe@...hat.com>, Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, 
	Lijo Lazar <lijo.lazar@....com>, linux-efi@...r.kernel.org, linux-fbdev@...r.kernel.org, 
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Lucas De Marchi <lucas.demarchi@...el.com>, Lyude Paul <lyude@...hat.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	"Mario Limonciello (AMD)" <superm1@...nel.org>, Mario Limonciello <mario.limonciello@....com>, 
	Maxime Ripard <mripard@...nel.org>, nouveau@...ts.freedesktop.org, 
	Rodrigo Vivi <rodrigo.vivi@...el.com>, Simona Vetter <simona@...ll.ch>, 
	spice-devel@...ts.freedesktop.org, 
	Thomas Hellström <thomas.hellstrom@...ux.intel.com>, 
	Timur Kristóf <timur.kristof@...il.com>, 
	Tvrtko Ursulin <tursulin@...ulin.net>, virtualization@...ts.linux.dev, 
	Vitaly Prosyak <vitaly.prosyak@....com>
Subject: Re: [PATCH 00/12] Recover sysfb after DRM probe failure

On Thu, Jan 15, 2026 at 6:02 AM Thomas Zimmermann <tzimmermann@...e.de> wrote:
>
> That's really not going to work. For example, in the current series, you
> invoke devm_aperture_remove_conflicting_pci_devices_done() after
> drm_mode_reset(), drm_dev_register() and drm_client_setup().

That's perfectly fine,
devm_aperture_remove_conflicting_pci_devices_done is removing the
reload behavior not doing anything.

This series, essentially, just adds a "defer" statement to
aperture_remove_conflicting_pci_devices that says

"reload sysfb if this driver unloads".

devm_aperture_remove_conflicting_pci_devices_done just cancels that defer.

You could ask why have
devm_aperture_remove_conflicting_pci_devices_done at all then and it's
because I didn't want to change the default behavior of anything.

There are three cases:
1) Driver fails to load before
aperture_remove_conflicting_pci_devices, in which case sysfb is still
active and there's no problem,
2) Driver fails to load after aperture_remove_conflicting_pci_devices,
in which case sysfb is gone and the screen is blank
3) Driver is unloaded after the probe succeeded. igt tests this too.

Without devm_aperture_remove_conflicting_pci_devices_done we'd try to
reload sysfb in #3, which, in general makes sense to me and I'd
probably remove it in my drivers, but there might be people or tests
(again, igt does it and we don't need to flip-flop between sysfb and
the driver there) that depend on specifically that behavior of not
having anything driving fb so I didn't want to change it.

So with this series the worst case scenario is that the driver that
failed after aperture_remove_conflicting_pci_devices changed the
hardware state so much that sysfb can't recover and the fb is blank.
So it was blank before and this series can't fix it because the driver
in its cleanup routine will need to do more unwinding for sysfb to
reload (i.e. we'd need an extra patch to unwind the driver state).
There also might be the case of some crazy behavior, e.g. pci bar
resize in the driver makes the vga hardware crash or something, in
which case, yea, we should definitely skip this patch, at least until
those drivers properly cleanup on exit.

z

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5414 bytes)