| Message ID | 20220504115917.758787-1-javierm@redhat.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Headers | show |
| Series | [v2] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered" | expand |
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).
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
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.
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)
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(-)