[PATCH v2] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"

[PATCH v2] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"

[Javier Martinez Canillas]

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
descriptor was closed.

The issue was exposed by commit 27599aacbaef ("fbdev: Hot-unplug firmware
fb devices on forced removal"), which added a new path that goes through
the struct device removal instead of directly unregistering the fb.

Most fbdev drivers have issues with the fb_info lifetime, because call to
framebuffer_release() from their driver's .remove callback, rather than
doing from fbops.fb_destroy callback. This meant that due to this switch,
the fb_info was now destroyed too early, while references still existed,
while before it was simply leaked.

The patch we're reverting here reinstated that leak, hence "fixed" the
regression. But the proper solution is to fix the drivers to not release
the fb_info too soon.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---

Changes in v2:
- Add more info in the commit message about why it's crashing and how
  the reverted commit was papering over the issue (Daniel Vetter).
- Add Daniel Vetter's Reviewed-by tag.

 drivers/video/fbdev/core/fbmem.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 97eb0dee411c..a6bb0e438216 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1434,10 +1434,7 @@ fb_release(struct inode *inode, struct file *file)
 __acquires(&info->lock)
 __releases(&info->lock)
 {
-	struct fb_info * const info = file_fb_info(file);
-
-	if (!info)
-		return -ENODEV;
+	struct fb_info * const info = file->private_data;
 
 	lock_fb_info(info);
 	if (info->fbops->fb_release)
-- 
2.35.1

Re: [PATCH v2] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"

[Javier Martinez Canillas]

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
> descriptor was closed.
> 
> The issue was exposed by commit 27599aacbaef ("fbdev: Hot-unplug firmware
> fb devices on forced removal"), which added a new path that goes through
> the struct device removal instead of directly unregistering the fb.
> 
> Most fbdev drivers have issues with the fb_info lifetime, because call to
> framebuffer_release() from their driver's .remove callback, rather than
> doing from fbops.fb_destroy callback. This meant that due to this switch,
> the fb_info was now destroyed too early, while references still existed,
> while before it was simply leaked.
> 
> The patch we're reverting here reinstated that leak, hence "fixed" the
> regression. But the proper solution is to fix the drivers to not release
> the fb_info too soon.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> 

Pushed this to drm-misc (drm-misc-fixes).

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v2] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"

[public]

Thanks for this patch. Do you think this can be backported to LTS 5.17.y and
5.15.y, which are still buggy? It's not a big deal for me but others might
profit.

Background:
The patch solves a regression from 5.17.1 to 5.17.2 or 5.15.32 and
5.15.33 I was about to report. On my Thinkpad T570, I got random "BUG", "Oops"
or even panics when during booting with efifb and plymouthd (and then sometimes
also problems when shutting down because). I had bisected the issue to commit
27599aacbaef. I could provide more info but I don't think it's necessary given
that either aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a or your better patch now
fixes the issue (I tested both, both work for me).

Best,
Tim Ruffing

Re: [PATCH v2] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"

[Javier Martinez Canillas]

Hello Tim,

On 5/9/22 16:01, public@timruffing.de wrote:
> Thanks for this patch. Do you think this can be backported to LTS 5.17.y and

You are welcome.

> 5.15.y, which are still buggy? It's not a big deal for me but others might
> profit.
>
> Background:
> The patch solves a regression from 5.17.1 to 5.17.2 or 5.15.32 and
> 5.15.33 I was about to report. On my Thinkpad T570, I got random "BUG", "Oops"
> or even panics when during booting with efifb and plymouthd (and then sometimes
> also problems when shutting down because). I had bisected the issue to commit
> 27599aacbaef. I could provide more info but I don't think it's necessary given
> that either aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a or your better patch now
> fixes the issue (I tested both, both work for me).
>

The patches to fix the fbdev 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