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] [day] [month] [year] [list]

Message-ID: <CABQX2QM0_6DJtrahJS7x9iF_wcSZRc4dohEiPnMCtAg7Vt7JPQ@mail.gmail.com>
Date: Sat, 17 Jan 2026 01:02:48 -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 Fri, Jan 16, 2026 at 2:58 AM Thomas Zimmermann <tzimmermann@...e.de> wrote:
>
> Hi
>
> Am 16.01.26 um 04:59 schrieb Zack Rusin:
> > 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.
>
> Exactly. And if that reload happens after the hardware state has been
> changed, the result is undefined.

This is all predicated on drivers actually cleaning up after
themselves. I don't think any amount of good will or api design is
going to fix device specific state mismatches.

> The current recovery/reload is not reliable in any case. A number of
> high-profile devs have also said that it doesn't work with their driver.
> The same is true for ast. So the current approach is not going to happen.
>
> > 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.
>
> There's nothing crazy here. It's standard probing code.
>
> If you want to to move forward, my suggestion is to look at the proposal
> with the aperture_funcs callbacks that control sysfb device access. And
> from there, build a full prototype with one or two drivers.

I don't think that approach is going to work. I don't think there's
anything that can be done if drivers didn't cleanup everything they've
done that might have broken sysfb on unload. I'm going to drop it
then, it's obviously a shame because it works fine with virtualized
drivers and they're ones that would likely profit from this the most
but I'm sceptical that I could do full system state set reset in a
generalized fashion for hw drivers or that the work required would be
worth the payoff.

z

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