RE: [PATCH 1/1] fbdev: hyperv_fb: iounmap() the correct memory when removing a device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Saurabh Singh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx> Sent: Monday, February 10, 2025 8:52 AM
> 
> On Mon, Feb 10, 2025 at 06:58:25AM -0800, Saurabh Singh Sengar wrote:
> > On Mon, Feb 10, 2025 at 02:28:35PM +0000, Michael Kelley wrote:
> > > From: Saurabh Singh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx> Sent: Monday, February 10, 2025 4:41 AM
> > > >
> > > > On Sun, Feb 09, 2025 at 03:52:52PM -0800, mhkelley58@xxxxxxxxx wrote:
> > > > > From: Michael Kelley <mhklinux@xxxxxxxxxxx>
> > > > >
> > > > > When a Hyper-V framebuffer device is removed, or the driver is unbound
> > > > > from a device, any allocated and/or mapped memory must be released. In
> > > > > particular, MMIO address space that was mapped to the framebuffer must
> > > > > be unmapped. Current code unmaps the wrong address, resulting in an
> > > > > error like:
> > > > >
> > > > > [ 4093.980597] iounmap: bad address 00000000c936c05c
> > > > >
> > > > > followed by a stack dump.
> > > > >
> > > > > Commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for
> > > > > Hyper-V frame buffer driver") changed the kind of address stored in
> > > > > info->screen_base, and the iounmap() call in hvfb_putmem() was not
> > > > > updated accordingly.
> > > > >
> > > > > Fix this by updating hvfb_putmem() to unmap the correct address.
> > > > >
> > > > > Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
> > > > > Signed-off-by: Michael Kelley <mhklinux@xxxxxxxxxxx>
> > > > > ---
> > > > >  drivers/video/fbdev/hyperv_fb.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> > > > > index 7fdb5edd7e2e..363e4ccfcdb7 100644
> > > > > --- a/drivers/video/fbdev/hyperv_fb.c
> > > > > +++ b/drivers/video/fbdev/hyperv_fb.c
> > > > > @@ -1080,7 +1080,7 @@ static void hvfb_putmem(struct hv_device *hdev, struct fb_info *info)
> > > > >
> > > > >  	if (par->need_docopy) {
> > > > >  		vfree(par->dio_vp);
> > > > > -		iounmap(info->screen_base);
> > > > > +		iounmap(par->mmio_vp);
> > > > >  		vmbus_free_mmio(par->mem->start, screen_fb_size);
> > > > >  	} else {
> > > > >  		hvfb_release_phymem(hdev, info->fix.smem_start,
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
> > > > Thanks for fixing this:
> > > > Reviewed-by: Saurabh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx>
> > > >
> > > >
> > > > While we are at it, I want to mention that I also observed below WARN
> > > > while removing the hyperv_fb, but that needs a separate fix.
> > > >
> > > >
> > > > [   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
> > > >
> > >
> > > Thanks for pointing this out. Interestingly, I'm not seeing this WARN
> > > in my experiments. What base kernel are you testing with? Are you
> > > testing on a local VM or in Azure? What exactly are you doing
> > > to create the problem? I've been doing unbind of the driver,
> > > but maybe you are doing something different.
> > >
> > > FWIW, there is yet another issue where after doing two unbind/bind
> > > cycles of the hyperv_fb driver, there's an error about freeing a
> > > non-existent resource. I know what that problem is, and it's in
> > > vmbus_drv.c. I'll be submitting a patch for that as soon as I figure out
> > > a clean fix.
> > >
> > > Michael
> >
> > This is on local Hyper-V. Kernel: 6.14.0-rc1-next-20250205+
> > I run below command to reproduce the above error:
> > echo "5620e0c7-8062-4dce-aeb7-520c7ef76171" >/sys/bus/vmbus/devices/5620e0c7-8062-4dce-aeb-520c7ef76171/driver/unbind
> >
> > When hvfb_remove is called I can see the refcount for framebuffer is 2 when ,
> > I expect it to be 1. After unregistering this framebuffer there is still 1 refcount
> > remains, which is the reason for this WARN at the time of framebuffer_release.
> >
> > I wonder who is registering/using this extra framebuffer. Its not hyperv_drm or
> > hyperv_fb IIUC.
> >
> > - Saurabh
> 
> Here are more details about this WARN:
> 
> Xorg opens `/dev/fb0`, which increases the framebuffer's reference
> count, as mentioned above.  As a result, when unbinding the driver,
> this WARN is expected, indicating that the framebuffer is still in use.
> 
> I am open to suggestion what could be the correct behavior in this case.
> There acan be two possible options:
> 
>  1. Check the framebuffer reference count and prevent the driver from
>     unbinding/removal.
> OR
> 
>  2. Allow the driver to unbind while issuing this WARN. (Current scenario)

OK, that makes sense. I haven't looked at or thought about this issue any
further today, and don't have an opinion yet. Give me a day or two -- I have
one more patch to post related to the FB and DRM driver problems.

Michael

> 
> - Saurabh






[Index of Archives]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Tourism]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux