From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
Junxiao Chang <junxiao.chang@intel.com>,
dri-devel@lists.freedesktop.org,
Maxime Ripard <maxime@cerno.tech>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH v2] fbdev: Use helper to get fb_info in all file operations
Date: Wed, 4 May 2022 13:35:37 +0200 [thread overview]
Message-ID: <da8874d4-66f1-d14e-c0ef-c3557e189cf4@redhat.com> (raw)
In-Reply-To: <d47a3cab-4f21-3b8b-2834-030663677070@suse.de>
Hello Thomas,
On 5/4/22 13:08, Thomas Zimmermann wrote:
[snip]
>>> So something similar to fb_file_fb_info() is needed to check if
>>> the vm_private_data is still valid. I guess that could be done
>>> by using the vmf->vma->vm_file and attempting the same trick that
>>> fb_file_fb_info() does ?
>>
>> Yeah should work, except if the ptes are set up already there's kinda not
>> much that this will prevent. We'd need to tear down mappings and SIGBUS or
>> alternatively have something else in place there so userspace doesn't blow
>> up in funny ways (which is what we're doing on the drm side, or at least
>> trying to).
>>
>> I'm also not sure how much we should care, since ideally for drm drivers
>> this is all taken care of by drm_dev_enter in the right places. It does
>> mean though that fbdev mmap either needs to have it's own memory or be
>> fully redirected to the drm gem mmap.
>>
>> And then we can afford to just not care to fix fbdev itself.
>
> While the problem has been there ever since, the bug didn't happen until
> we fixed hot-unplugging for fbdev. Not doing anything is probably not
> the right thing.
>
Actually, this issue shouldn't happen if the fbdev drivers are not buggy
and do the proper cleanup at .fb_release() time rather than at .remove().
I'll post patches for simplefb and efifb which are the drivers that we
mostly care at this point. So we should be good and not need more fixes.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
prev parent reply other threads:[~2022-05-04 11:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 20:19 [PATCH v2] fbdev: Use helper to get fb_info in all file operations Javier Martinez Canillas
2022-05-03 20:53 ` Sam Ravnborg
2022-05-04 8:15 ` Thomas Zimmermann
2022-05-04 8:26 ` Javier Martinez Canillas
2022-05-04 9:02 ` Daniel Vetter
2022-05-04 9:27 ` Thomas Zimmermann
2022-05-04 9:28 ` Javier Martinez Canillas
2022-05-04 10:55 ` Daniel Vetter
2022-05-04 11:08 ` Thomas Zimmermann
2022-05-04 11:35 ` Javier Martinez Canillas [this message]
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=da8874d4-66f1-d14e-c0ef-c3557e189cf4@redhat.com \
--to=javierm@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=junxiao.chang@intel.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime@cerno.tech \
--cc=sam@ravnborg.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 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).