On Tue, Feb 25, 2025 at 04:46:12PM +0000, Michael Kelley wrote:
> From: Saurabh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx>
> >
> > When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to
> > release the framebuffer forcefully. If this framebuffer is in use it
> > produce the following WARN and hence this framebuffer is never released.
> >
> > [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70
> > framebuffer_release+0x2c/0x40
> > < snip >
> > [ 44.111289] Call Trace:
> > [ 44.111290] <TASK>
> > [ 44.111291] ? show_regs+0x6c/0x80
> > [ 44.111295] ? __warn+0x8d/0x150
> > [ 44.111298] ? framebuffer_release+0x2c/0x40
> > [ 44.111300] ? report_bug+0x182/0x1b0
> > [ 44.111303] ? handle_bug+0x6e/0xb0
> > [ 44.111306] ? exc_invalid_op+0x18/0x80
> > [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20
> > [ 44.111311] ? framebuffer_release+0x2c/0x40
> > [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb]
> > [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus]
> > [ 44.111323] device_remove+0x40/0x80
> > [ 44.111325] device_release_driver_internal+0x20b/0x270
> > [ 44.111327] ? bus_find_device+0xb3/0xf0
> >
> > Fix this by moving the release of framebuffer and assosiated memory
> > to fb_ops.fb_destroy function, so that framebuffer framework handles
> > it gracefully.
> >
> > While we fix this, also replace manual registrations/unregistration of
> > framebuffer with devm_register_framebuffer.
> >
> > Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer
> > Driver")
> > Signed-off-by: Saurabh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx>
> > ---
> > V2 : Move hvfb_putmem into destroy()
> >
> > drivers/video/fbdev/hyperv_fb.c | 28 ++++++++++++++++++++++------
> > 1 file changed, 22 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> > index 363e4ccfcdb7..89ee49f1c3dc 100644
> > --- a/drivers/video/fbdev/hyperv_fb.c
> > +++ b/drivers/video/fbdev/hyperv_fb.c
> > @@ -282,6 +282,8 @@ static uint screen_depth;
> > static uint screen_fb_size;
> > static uint dio_fb_size; /* FB size for deferred IO */
> >
> > +static void hvfb_putmem(struct hv_device *hdev, struct fb_info *info);
> > +
> > /* Send message to Hyper-V host */
> > static inline int synthvid_send(struct hv_device *hdev,
> > struct synthvid_msg *msg)
> > @@ -862,6 +864,24 @@ static void hvfb_ops_damage_area(struct fb_info *info, u32 x,
> > u32 y, u32 width,
> > hvfb_ondemand_refresh_throttle(par, x, y, width, height);
> > }
> >
> > +/*
> > + * fb_ops.fb_destroy is called by the last put_fb_info() call at the end
> > + * of unregister_framebuffer() or fb_release(). Do any cleanup related to
> > + * framebuffer here.
> > + */
> > +static void hvfb_destroy(struct fb_info *info)
> > +{
> > + struct hv_device *hdev;
> > + struct device *dev;
> > + void *driver_data = (void *)info;
> > +
> > + dev = container_of(driver_data, struct device, driver_data);
>
> I don't think the above is right. The struct fb_info was allocated
> with kzalloc() in framebuffer_alloc(). You would use container_of()
> if fb_info was embedded in a struct device, but that's not the case
> here. The driver_data field within the struct device is a pointer to the
> fb_info, but that doesn't help find the struct device.
Thanks for catching this. I should have been more careful.
>
> What does help is that info->device (not to be confused with info->dev,
> which is a different struct device) points to the struct device that
> you need here. That "device" field is set in framebuffer_alloc().
> So that's an easy fix.
Right, thanks.
>
> > + hdev = container_of(dev, struct hv_device, device);
> > +
> > + hvfb_putmem(hdev, info);
>
> Another observation: The interface to hvfb_putmem() is more
> complicated than it needs to be. The hdev argument could be
> dropped because it is used only to get the device pointer,
> which is already stored in info->device. hvfb_release_phymem()
> would also need to be updated to take a struct device instead of
> struct hv_device. But if you made those changes, then the
> container_of() to get the hdev wouldn't be needed either.
Make sense.
>
> A similar simplification could be applied to hvfb_getmem().
>
> Maybe do two patches -- the first to simplify the interfaces,
> and the second to do this patch but with reduced
> complexity because of the simpler interfaces.
Agree, let me do it in V3.
- Saurabh
>
> Michael
>
<snip>
