From: Javier Martinez Canillas <javierm@redhat.com>
To: Alex Deucher <alexander.deucher@amd.com>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org,
Alex Deucher <alexander.deucher@amd.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Helge Deller <deller@gmx.de>, Sam Ravnborg <sam@ravnborg.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
stable@vger.kernel.org
Subject: Re: [PATCH V3] video/aperture: optionally match the device in sysfb_disable()
Date: Thu, 22 Aug 2024 16:51:04 +0200 [thread overview]
Message-ID: <874j7ca9wn.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <20240821191135.829765-1-alexander.deucher@amd.com>
Alex Deucher <alexander.deucher@amd.com> writes:
Hello Alex,
> In aperture_remove_conflicting_pci_devices(), we currently only
> call sysfb_disable() on vga class devices. This leads to the
> following problem when the pimary device is not VGA compatible:
>
> 1. A PCI device with a non-VGA class is the boot display
> 2. That device is probed first and it is not a VGA device so
> sysfb_disable() is not called, but the device resources
> are freed by aperture_detach_platform_device()
> 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable()
> 4. NULL pointer dereference via sysfb_disable() since the resources
> have already been freed by aperture_detach_platform_device() when
> it was called by the other device.
>
> Fix this by passing a device pointer to sysfb_disable() and checking
> the device to determine if we should execute it or not.
>
> v2: Fix build when CONFIG_SCREEN_INFO is not set
> v3: Move device check into the mutex
> Drop primary variable in aperture_remove_conflicting_pci_devices()
> Drop __init on pci sysfb_pci_dev_is_enabled()
>
> Fixes: 5ae3716cfdcd ("video/aperture: Only remove sysfb on the default vga pci device")
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> Cc: stable@vger.kernel.org
> ---
This version looks good to me. Thanks!
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
next prev parent reply other threads:[~2024-08-22 14:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-21 19:11 [PATCH V3] video/aperture: optionally match the device in sysfb_disable() Alex Deucher
2024-08-21 20:18 ` ✗ Fi.CI.BAT: failure for " Patchwork
2024-08-22 14:51 ` Javier Martinez Canillas [this message]
2024-08-22 15:10 ` [PATCH V3] " Thomas Zimmermann
2024-08-22 15:12 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874j7ca9wn.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel.vetter@ffwll.ch \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=sam@ravnborg.org \
--cc=stable@vger.kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.