r the simple framebuffer devices,
so an unregistration has to be forced by fbmem if sysfb_try_unregister()
does not succeed at unregister the device.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
Changes in v4:
- Drop call to sysfb_disable() in
and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Cc: Thomas Zimmermann
Cc: Zack Rusin
Cc: Javier Martinez Canillas
Cc: Zack Rusin
Cc: Hans de Goede
Cc: Ilya Trukhanov
Signed-off-by: Daniel Vetter
Signed-off-
: linux-stag...@lists.linux.dev
Signed-off-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Reviewed-by: Javier Martinez Canillas
Cc: Daniel Vetter
Cc: Helge Deller
Cc: Matthew Wilcox
Cc: Sam Ravnborg
Cc: Tetsuo Handa
Cc: Zhen Lei
Cc: Alex Deucher
Cc: Xiyu Yang
Cc: linux-fb...@vger.kernel.org
Hello Thomas,
On 4/29/22 11:14, Thomas Zimmermann wrote:
> Hi
>
> Am 29.04.22 um 10:42 schrieb Javier Martinez Canillas:
>> The DRIVER_FIRMWARE flag denotes that a DRM driver uses a framebuffer
>> that was initialized and provided by the system firmware for scanout.
>&g
eries ? Then the patches would only be
1) renaming preferred_bpp (that would be unused at this point) to flags
and 2) make simpledrm to set FBDEV_FIRMWARE flag or something like that.
Another option is to add a third flags param to drm_fbdev_generic_setup()
and make all drivers to set 0 besides si
[0]: https://lore.kernel.org/lkml/20220429084253.1085911-1-javi...@redhat.com/
Javier Martinez Canillas (3):
drm: Remove superfluous arg when calling to drm_fbdev_generic_setup()
drm/fb-helper: Rename preferred_bpp drm_fbdev_generic_setup()
parameter
drm: Allow simpledrm to setup its em
: Javier Martinez Canillas
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv
ann
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 --
drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
drivers/gpu/drm/arm/malidp_drv.c| 2 +-
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +-
drivers/gpu/drm/
.
Drivers can use this to indicate the FB helper initialization that the FB
registered is provided by the firmware, so it can be configured as such.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 9 +
drivers/gpu/drm/tiny
Hello Thomas,
On 5/2/22 12:35, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 02.05.22 um 10:48 schrieb Javier Martinez Canillas:
>> Hello,
>>
>> This series contain patches suggested by Thomas Zimmermannas a feedback for
Ups, I missed a space here. I meant to writ
tches in a rpi4 with both simplefb and vc4 drivers
built-in and did not find any regression.
[0]: https://github.com/raspberrypi/linux/issues/5011
Best regards,
Javier
Javier Martinez Canillas (2):
fbdev: Check in file_fb_info() if the fb_info was already been freed
fbdev: Make fb_re
-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fbmem.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 84427470367b..20d8929df79f 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b
.
This can happen for example if the fbdev driver was one that is using a
framebuffer provided by the system firmware. In that case, the fbdev core
could unregister the framebuffer device if a real video driver is probed.
Reported-by: Maxime Ripard
Signed-off-by: Javier Martinez Canillas
rename DRM_FB_SET_OPTION() to DRM_FB_OPTION() as it's
> computing the value of the option bitfield, it doesn't actually set it.
> Apart from that,
>
Right. I'll rename it.
> Reviewed-by: Laurent Pinchart
>
Thanks!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
On 5/2/22 15:26, Thomas Zimmermann wrote:
> Hi
>
> Am 02.05.22 um 15:09 schrieb Javier Martinez Canillas:
>> If real driver probes, the fbdev core kicks out all drivers that are using
>> a framebuffer that were provided by the system firmware. But it cou
Hello Thomas,
On 5/2/22 15:20, Thomas Zimmermann wrote:
>
>
> Am 02.05.22 um 15:09 schrieb Javier Martinez Canillas:
>> A reference to the framebuffer device struct fb_info is stored in the file
>> private data, but this reference could no longer be valid and must not be
d removal")
Reported-by: Maxime Ripard
Reported-by: Junxiao Chang
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
Changes in v2:
- Drop patch 1/2 since patch 2/2 should be enough to fix the issue.
- Add missing Fixes and Reported-by tags (Thomas Zimmermann).
ded.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
---
Changes in v2:
- Rename DRM_FB_SET_OPTION() to DRM_FB_SET() and make more clear in the
kernel-doc what this macro does (Laurent Pinchart).
- Fix some kernel-
c issues I didn't notice in v1.
- Add Reviewed-by tags from Thomas and Laurent.
Javier Martinez Canillas (3):
drm: Remove superfluous arg when calling to drm_fbdev_generic_setup()
drm/fb-helper: Rename preferred_bpp drm_fbdev_generic_setup()
parameter
drm: Allow simpledrm to setup i
.
Drivers can use this to indicate the FB helper initialization that the FB
registered is provided by the firmware, so it can be configured as such.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
(no changes since v1)
drivers/gpu/drm
: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
(no changes since v1)
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_d
Hello Laurent,
On 5/2/22 18:06, Laurent Pinchart wrote:
> Hi Javier,
>
> Thank you for the patch.
>
> On Mon, May 02, 2022 at 05:38:58PM +0200, Javier Martinez Canillas wrote:
>> The drm_fbdev_generic_setup() function already sets the preferred bits per
>>
On 5/2/22 18:07, Laurent Pinchart wrote:
> Hi Javier,
>
> Thank you for the patch.
>
> On Mon, May 02, 2022 at 05:38:59PM +0200, Javier Martinez Canillas wrote:
>> By default the bits per pixel for the emulated framebuffer device is set
>> to dev->mode_config.pre
Hello Laurent,
On 5/2/22 18:17, Laurent Pinchart wrote:
> Hi Javier,
>
> Thank you for the patch.
>
> On Mon, May 02, 2022 at 05:39:00PM +0200, Javier Martinez Canillas wrote:
>> Indicate to fbdev subsystem that the registered framebuffer is provided by
>> the syst
On 5/2/22 18:55, Javier Martinez Canillas wrote:
[snip]
>
>> drop the depth option to drm_fbdev_generic_setup() ? There's a FIXME
>> comment in drm_fbdev_generic_setup() that could be related.
>>
>
> A FIXME makes sense, I'll add that to when posting a v3.
On 5/2/22 20:36, Laurent Pinchart wrote:
> On Mon, May 02, 2022 at 07:15:16PM +0200, Javier Martinez Canillas wrote:
>> On 5/2/22 18:55, Javier Martinez Canillas wrote:
>>
>> [snip]
>>
>>>> drop the depth option to drm_fbdev_generic_setup() ? There's a F
odified.
>
Right. I'll also do the same for the preferred_bpp variable in patch 2/3
if I choose to keep them in v3.
Thanks again for your feedback and comments!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
PTION() and make more clear in
the kernel-doc what this macro does (Laurent Pinchart).
- Fix some kernel-doc issues I didn't notice in v1.
- Add Reviewed-by tags from Thomas and Laurent.
Javier Martinez Canillas (3):
drm: Remove superfluous arg when calling to drm_fbdev_generic_setup()
: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
---
(no changes since v1)
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
ded.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
---
Changes in v3:
- Drop the preferred_bpp local variable (Laurent Pinchart).
- Add a const qualifier to options parameter (Laurent Pinchart).
Changes in
.
Drivers can use this to indicate the FB helper initialization that the FB
registered is provided by the firmware, so it can be configured as such.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
---
Changes
forth.
If is just that the naming haven't been used consistently, maybe this rework
(or a follow-up) could be an opportunity to add consistency in that regard.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
I'm not asking to do it as a part of this series but something that
we may do as a follow-up though, just mentioning.
I'll post a patch to add that task to Documentation/gpu/todo.rst,
so it is tracked somewhere.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 4/27/22 16:14, Thomas Zimmermann wrote:
> Give each per-line conversion helper pointers of type void and the
> number of pixels in the line. Remove the unused swab parameters.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best r
the generic implementation.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 5/2/22 15:50, Javier Martinez Canillas wrote:
> A reference to the framebuffer device struct fb_info is stored in the file
> private data, but this reference could no longer be valid and must not be
> accessed directly. Instead, the file_fb_info() accessor function must be
> used s
nxiao Chang
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fb_defio.c | 5 -
drivers/video/fbdev/core/fbmem.c| 24 +++-
include/linux/fb.h | 1 +
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/video/
nxiao Chang
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Fix copy & paste error passing file->private_data instead of file
to fb_file_fb_info() function (Sam Ravnborg).
drivers/video/fbdev/core/fb_defio.c | 5 -
drivers/video/fbdev/core/fbm
fo *info = fb_file_fb_info(file->private_data);
> This looks wrong. I assume you wanted to write:
>> +struct fb_info *info = fb_file_fb_info(file);
Right I did. Thanks for pointing out.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
The Kernel Unit Testing (KUnit) framework provides a common framework for
unit tests within the Linux kernel. Having a test suite would allow to
identify regressions earlier.
Signed-off-by: Javier Martinez Canillas
---
Documentation/gpu/todo.rst | 14 ++
1 file changed, 14
Hello Thomas,
On 5/4/22 10:15, Thomas Zimmermann wrote:
> Hi
>
> Am 03.05.22 um 22:19 schrieb Javier Martinez Canillas:
>> A reference to the framebuffer device struct fb_info is stored in the file
>> private data, but this reference could no longer be valid and must not be
Hello Maxime,
Thanks for your feedback.
On 5/4/22 10:10, Maxime Ripard wrote:
> Hi,
>
> On Wed, May 04, 2022 at 10:02:12AM +0200, Javier Martinez Canillas wrote:
>> The Kernel Unit Testing (KUnit) framework provides a common framework for
>> unit tests within the Linux
Hello Daniel,
On 5/4/22 11:02, Daniel Vetter wrote:
> On Tue, May 03, 2022 at 10:19:34PM +0200, Javier Martinez Canillas wrote:
>> A reference to the framebuffer device struct fb_info is stored in the file
>> private data, but this reference could no longer be valid and must not
Hello Daniel,
On 5/4/22 11:47, Daniel Vetter wrote:
> On Mon, May 02, 2022 at 03:09:44PM +0200, Javier Martinez Canillas wrote:
>> A reference to the framebuffer device struct fb_info is stored in the file
>> private data, but this reference could no longer be valid and must not
papering over the issue, and
also would leak any resources that might be reference counted in fb_open.
Instead, the fbdev drivers that are releasing the fb_info too soon should
be fixed to prevent this situation to happen.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
On 5/4/22 12:58, Daniel Vetter wrote:
> On Tue, May 03, 2022 at 09:15:40AM +0200, Javier Martinez Canillas wrote:
>> Indicate to fbdev subsystem that the registered framebuffer is provided by
>> the system firmware, so that it can handle accordingly. For example, would
>> unre
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
ssion. But the proper solution is to fix the drivers to not release
the fb_info too soon.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
Changes in v2:
- Add more info in the commit message about why it's crashing and how
the reverted
ays attached (v3)").
>
I would write this line instead as:
in commit f95af4a9236695 ("drm/amdgpu: don't runtime suspend if there are
displays attached (v3)").
> Signed-off-by: Alex Deucher
> ---
The patch looks good to me.
Reviewed-by: Javier Martinez Canill
und is no longer necessary. Since amdgpu was the only
> user of this interface, we can remove it.
>
> Signed-off-by: Alex Deucher
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 5/4/22 18:50, Alex Deucher wrote:
> On Wed, May 4, 2022 at 12:46 PM Javier Martinez Canillas
> wrote:
>>
>> Hello Alex,
>>
>> On 5/4/22 15:48, Alex Deucher wrote:
>>> This reverts commit b95dc06af3e683d6b7ddbbae178b2b2a21ee8b2b.
>>>
>>>
Vetter (1):
fbdev: Prevent possible use-after-free in fb_release()
Javier Martinez Canillas (2):
fbdev/simplefb: Cleanup fb_info in .fb_destroy rather than .remove
fbdev/efifb: Cleanup fb_info in .fb_destroy rather than .remove
drivers/video/fbdev/core/fbsysfs.c | 4
drivers/video/fbd
exist, leading to a use-after-free error.
To prevent this, check the fb_info reference counter when attempting to
kfree the data structure in framebuffer_release(). That will leak it but
at least will prevent the mentioned error.
Signed-off-by: Daniel Vetter
Signed-off-by: Javier Martinez Can
unregistered but later a user-space process tries to close the fbdev fd.
The correct thing to do is to only unregister the framebuffer in the
driver's .remove callback, but do any cleanup in the fb_ops.fb_destroy.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
drivers/
unregistered but later a user-space process tries to close the fbdev fd.
The correct thing to do is to only unregister the framebuffer in the
driver's .remove callback, but do any cleanup in the fb_ops.fb_destroy.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
drivers/
ndler
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.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
hat we
shouldn't try to fix all possible corner cases and just try to get rid
of fbdev as soon as possible.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
e the resources at the correct place.
>
> From a quick look, vesafb seems to be affected as well.
>
Right, I wrongly assumed that we only cared about efifb and simplefb but forgot
that vesafb is used when setting a VESA mode with vga=foo. I'll add it in a v2.
> Best regards
> Thom
On 5/4/22 10:02, Javier Martinez Canillas wrote:
> The Kernel Unit Testing (KUnit) framework provides a common framework for
> unit tests within the Linux kernel. Having a test suite would allow to
> identify regressions earlier.
>
> Signed-off-by: Javier Martinez Canillas
>
nges in v2:
- Also do the change for vesafb (Thomas Zimmermann).
Daniel Vetter (1):
fbdev: Prevent possible use-after-free in fb_release()
Javier Martinez Canillas (3):
fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove
fbdev: efifb: Cleanup fb_info in .fb_destroy rather th
exist, leading to a use-after-free error.
To prevent this, check the fb_info reference counter when attempting to
kfree the data structure in framebuffer_release(). That will leak it but
at least will prevent the mentioned error.
Signed-off-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Rev
unregistered but later a user-space process tries to close the fbdev fd.
The correct thing to do is to only unregister the framebuffer in the
driver's .remove callback, but do any cleanup in the fb_ops.fb_destroy.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: T
unregistered but later a user-space process tries to close the fbdev fd.
The correct thing to do is to only unregister the framebuffer in the
driver's .remove callback, but do any cleanup in the fb_ops.fb_destroy.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: T
unregistered but later a user-space process tries to close the fbdev fd.
The correct thing to do is to only unregister the framebuffer in the
driver's .remove callback, but do any cleanup in the fb_ops.fb_destroy.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
Changes
: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index f2a6b81e45c4..bd849013f16f 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -616,7
that point we shouldn't need
> special flags anymore.
I'm OK with this take and happy to just drop this patch-set then. My worry
was just that someone could complain that we broke their uncommon setup [0].
[0]: https://xkcd.com/1172/.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Daniel,
On 5/5/22 14:52, Daniel Vetter wrote:
> On Wed, May 04, 2022 at 11:57:22PM +0200, Javier Martinez Canillas wrote:
>> The driver is calling framebuffer_release() in its .remove callback, but
>> this will cause the struct fb_info to be freed too early. Since it cou
s them. But I
will only move the framebuffer_release() that is the problematic bit.
Someone if care enough could fix the rest of the driver.
> Also same comments as on v1 about adding more details about what/how this
> fixes, with that: Reviewed-by: Daniel Vetter
>
Yes, I'll do that too. Thanks again for your comments and feedback.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Thomas asked me to serve as co-maintainer for the simpledrm driver.
Signed-off-by: Javier Martinez Canillas
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1a04950c1a8f..bfe43560f9d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6389,6
vesafb (Thomas Zimmermann).
Daniel Vetter (1):
fbdev: Prevent possible use-after-free in fb_release()
Javier Martinez Canillas (3):
fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove
fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove
fbdev: vesafb: Cle
exist, leading to a use-after-free error.
To prevent this, check the fb_info reference counter when attempting to
kfree the data structure in framebuffer_release(). That will leak it but
at least will prevent the mentioned error.
Signed-off-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Rev
aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
(no changes since v1)
drivers/video/fbdev/simplefb.c | 8 +++-
1 file changed, 7
aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
(no changes since v1)
drivers/video/fbdev/efifb.c | 9 -
1 file changed, 8
aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
Changes in v3:
- Only move framebuffer_release() and don't do any other change
(
5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Abhinav Kumar
---
Changes in v4:
- Remove the kernel log timestamps and just keep the stacktrace (Abhinav Kumar).
- Add Abhinav Kumar Reviewed-by tag.
Changes in v3:
On 5/4/22 13:59, Javier Martinez Canillas wrote:
> This reverts commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a. That commit
> attempted to fix a NULL pointer dereference, caused by the struct fb_info
> associated with a framebuffer device to not longer be valid when the file
> de
On 5/5/22 23:59, Javier Martinez Canillas wrote:
> Hello,
>
> This series contains patches suggested by Daniel Vetter to fix a
> use-after-free
> error in the fb_release() function, due a fb_info associated with a fbdev
> being
> freed too early while a user-space proces
Hello Andrzej,
On 5/6/22 15:07, Andrzej Hajda wrote:
> On 06.05.2022 00:05, Javier Martinez Canillas wrote:
[snip]
>> +
>> +framebuffer_release(info);
>> +
>> if (request_mem_succeeded)
>> release_mem_regio
since the
fb_info was still used after the free.
This should fix for good by freeing the fb_info at the end of the handler.
Fixes: d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than
.remove")
Reported-by: Ville Syrjälä
Reported-by: Andrzej Hajda
Signed-off-by: Javi
Hello Lucas,
On 5/7/22 18:20, Lucas De Marchi wrote:
> On Fri, May 06, 2022 at 03:22:25PM +0200, Javier Martinez Canillas wrote:
>> Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather
>> than .remove") attempted to fix a use-after-free error due driv
k: https://bugzilla.redhat.com/show_bug.cgi?id=2072556
> Signed-off-by: Hans de Goede
> ---
Zack fixed this already:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=5405d25b9e8e6
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
fixed this already:
>>
>> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=5405d25b9e8e6
>
> I see, but it seems that this was never pushed to drm-misc-fixes,
> so this is still broken in 5.18-rc#
>
Indeed. Agreed that should be cherry-picked in -fixes as well.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Many of the kselftests in DRM can be converted to kunit tests instead,
since that framework is more suitable for unit testing.
Suggested-by: Maxime Ripard
Signed-off-by: Javier Martinez Canillas
---
Documentation/gpu/todo.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a
v hot-unplug regression will get merged in mainline
soon and since all have a Fixes tag, they should get picked for stable as well.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Andrzej,
On 5/9/22 16:56, Andrzej Hajda wrote:
> On 06.05.2022 00:04, Javier Martinez Canillas wrote:
>> From: Daniel Vetter
>>
>> Most fbdev drivers have issues with the fb_info lifetime, because call to
>> framebuffer_release() from their driver's .remov
fb expert so happy to move fb_dealloc_cmap() as well if that
is the correct thing to do.
[0]: https://www.spinics.net/lists/dri-devel/msg346257.html
[1]: https://www.spinics.net/lists/dri-devel/msg346261.html
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
On 5/9/22 20:32, Thomas Zimmermann wrote:
> Hi
>
> Am 09.05.22 um 18:33 schrieb Javier Martinez Canillas:
>> On 5/9/22 17:51, Andrzej Hajda wrote:
>>
>> [snip]
>>
>>>>>> +
>>>>> Regarding drm:
>>>
nfo)
{
+ if (info->cmap.len)
+ fb_dealloc_cmap(&info->cmap);
+
drm_fbdev_release(info->par);
+ framebuffer_release(info);
}
static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
_destroy() anyways.
We should probably remove that call in all drivers and make this helper
function static and just private to drm_fb_helper functions.
Or am I missing something here ?
[0]:
>From 5170cafcf2936da8f1c53231e3baa7d7a2b16c61 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canilla
On 5/10/22 09:19, Andrzej Hajda wrote:
>
>
> On 10.05.2022 00:42, Javier Martinez Canillas wrote:
>> On 5/10/22 00:22, Andrzej Hajda wrote:
>>
>> [snip]
>>
>>>>static void drm_fbdev_fb_destroy(struct fb_info *in
Hello Thomas,
On 5/10/22 10:04, Thomas Zimmermann wrote:
> Hi
>
> Am 10.05.22 um 00:42 schrieb Javier Martinez Canillas:
>> On 5/10/22 00:22, Andrzej Hajda wrote:
>>
>> [snip]
>>
>>>>static void drm_fbdev_fb_destroy(struct fb_info *in
it.
3) Set .fb_destroy to drm_fbdev_fb_destroy() if isn't set by drivers when
they call drm_fb_helper_initial_config() or drm_fb_helper_fill_info().
I'm leaning towards option (3). Then the fb_info release will be automatic
whether drivers are using the generic setup or a custom one.
ttern.
>
Right. We can't really abstract this away from drivers that are not
using the generic fbdev helpers. So then they will have to provide
their own .fb_destroy() callback and do the cleanup.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 5/5/22 19:26, Javier Martinez Canillas wrote:
> Thomas asked me to serve as co-maintainer for the simpledrm driver.
>
> Signed-off-by: Javier Martinez Canillas
> ---
Pushed this to drm-misc (drm-misc-next).
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 5/9/22 15:08, Javier Martinez Canillas wrote:
> Many of the kselftests in DRM can be converted to kunit tests instead,
> since that framework is more suitable for unit testing.
>
> Suggested-by: Maxime Ripard
> Signed-off-by: Javier Martinez Canillas
> ---
Pushed this to
- Add Daniel Reviewed-by tags to the patches.
Daniel Vetter (2):
Revert "fbdev: Prevent probing generic drivers if a FB is already
registered"
fbdev: Make registered_fb[] private to fbmem.c
Javier Martinez Canillas (5):
firmware: sysfb: Make sysfb_create_simplefb() return a pdev
This function just returned 0 on success or an errno code on error, but it
could be useful for sysfb_init() callers to have a pointer to the device.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
Reviewed-by: Thomas Zimmermann
---
(no changes since v3)
Changes in v3
These can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
(no changes since v4)
Changes in v4:
- Make
restart.
Since the framebuffer devices will already be removed, the loop would just
finish when no more conflicting framebuffers are found.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
(no changes since v1)
drivers/video/fbdev/core/fbmem.c
r the simple framebuffer devices,
so an unregistration has to be forced by fbmem if sysfb_try_unregister()
does not succeed at unregister the device.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
(no changes since v4)
Changes in v4:
- Drop ca
601 - 700 of 2340 matches
Mail list logo
