linux-kernel - Re: [PATCH v2] fbdev: hyperv_fb: Allow graceful removal of framebuffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250226035853.GA19981@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date: Tue, 25 Feb 2025 19:58:53 -0800
From: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
To: Michael Kelley <mhklinux@...look.com>
Cc: "kys@...rosoft.com" <kys@...rosoft.com>,
	"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>,
	"decui@...rosoft.com" <decui@...rosoft.com>,
	"deller@....de" <deller@....de>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ssengar@...rosoft.com" <ssengar@...rosoft.com>
Subject: Re: [PATCH v2] fbdev: hyperv_fb: Allow graceful removal of
 framebuffer

On Tue, Feb 25, 2025 at 04:46:12PM +0000, Michael Kelley wrote:
> From: Saurabh Sengar <ssengar@...ux.microsoft.com>
> > 
> > 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@...ux.microsoft.com>
> > ---
> > 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>