From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
linux-kernel@vger.kernel.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
linux-fbdev@vger.kernel.org, Helge Deller <deller@gmx.de>,
dri-devel@lists.freedesktop.org,
Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH 2/3] fbdev/simplefb: Cleanup fb_info in .fb_destroy rather than .remove
Date: Thu, 5 May 2022 10:05:33 +0200 [thread overview]
Message-ID: <78167587-fd2e-354c-485b-db4ee9251178@suse.de> (raw)
In-Reply-To: <d9a5cb30-2d9b-50b5-d287-0ead0fe252f3@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2308 bytes --]
Hi
Am 05.05.22 um 09:38 schrieb Javier Martinez Canillas:
> Hello Thomas,
>
> On 5/5/22 09:29, Thomas Zimmermann wrote:
>
> [snip]
>
>>> static void simplefb_destroy(struct fb_info *info)
>>> {
>>> struct simplefb_par *par = info->par;
>>> @@ -94,6 +98,8 @@ static void simplefb_destroy(struct fb_info *info)
>>> if (info->screen_base)
>>> iounmap(info->screen_base);
>>>
>>> + framebuffer_release(info);
>>> +
>>> if (mem)
>>> release_mem_region(mem->start, resource_size(mem));
>>
>> The original problem with fbdev hot-unplug was that vmwgfx needed the
>> framebuffer region to be released. If we release it only after userspace
>> closed it's final file descriptor, vmwgfx could have already failed.
>>
>> I still don't fully get why this code apparently works or at least
>> doesn't blow up occasionally. Any ideas?
>>
>
> I believe that vmwgfx doesn't fail to probe (or any other DRM driver)
> only when there are not user-space processes with a fbdev node opened
> since otherwise as you said the memory wouldn't be released yet.
>
> unregister_framebuffer() is called from the driver's .remove handler
> and that decrement the fb_info refcount, so if reaches zero it will
> call to the fb fops .destroy() handler and release the I/O memory.
>
> 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.
Of course, it's always been broken (even long before real fbdev
hotunplugging). Switching to simpledrm resolves the problem.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v5.17.5/source/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c#L727
--
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2022-05-05 8:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-04 21:51 [PATCH 0/3] fbdev: Fix use-after-free caused by wrong fb_info cleanup in drivers Javier Martinez Canillas
2022-05-04 21:56 ` [PATCH 1/3] fbdev: Prevent possible use-after-free in fb_release() Javier Martinez Canillas
2022-05-05 7:31 ` Thomas Zimmermann
2022-05-04 21:57 ` [PATCH 2/3] fbdev/simplefb: Cleanup fb_info in .fb_destroy rather than .remove Javier Martinez Canillas
2022-05-05 7:29 ` Thomas Zimmermann
2022-05-05 7:38 ` Javier Martinez Canillas
2022-05-05 8:05 ` Thomas Zimmermann [this message]
2022-05-05 8:28 ` Javier Martinez Canillas
2022-05-05 8:49 ` Thomas Zimmermann
2022-05-05 12:57 ` Daniel Vetter
2022-05-05 12:52 ` Daniel Vetter
2022-05-05 12:57 ` Javier Martinez Canillas
2022-05-04 21:58 ` [PATCH 3/3] fbdev/efifb: " Javier Martinez Canillas
2022-05-05 7:30 ` Thomas Zimmermann
2022-05-05 8:16 ` [PATCH 0/3] fbdev: Fix use-after-free caused by wrong fb_info cleanup in drivers Thomas Zimmermann
2022-05-05 8:30 ` Javier Martinez Canillas
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=78167587-fd2e-354c-485b-db4ee9251178@suse.de \
--to=tzimmermann@suse.de \
--cc=daniel.vetter@ffwll.ch \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=javierm@redhat.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).