Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Fri, Nov 20, 2020 at 02:00:55PM +0300, Dan Carpenter wrote: > On Fri, Nov 20, 2020 at 10:39:45AM +0100, Daniel Vetter wrote: > > On Fri, Nov 20, 2020 at 8:58 AM Dan Carpenter > > wrote: > > > > > > On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote: > > > > On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter > > > > wrote: > > > > > > > > > > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote: > > > > > > Hi, > > > > > > > > > > > > On 10/27/20 2:51 PM, Hans de Goede wrote: > > > > > > > Add missing pci_iounmap() calls to properly unmap the memory on > > > > > > > probe-failure and remove. > > > > > > > > > > > > > > Reported-by: kernel test robot > > > > > > > Reported-by: Dan Carpenter > > > > > > > Signed-off-by: Hans de Goede > > > > > > > > > > > > For some reason the spam-filter used by Red Hat's email system has > > > > > > eaten > > > > > > Daniel Vetter's reply to this, so let me copy and paste that from > > > > > > patchwork: > > > > > > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > I think switching over to devm would be really nice. And for pci > > > > > > > all > > > > > > > you need to do is use pcim_enable_device and delete all the > > > > > > > cleanup > > > > > > > code, and it's all done. Hand rolling device cleanup code really > > > > > > > isn't > > > > > > > a great idea and way too error-prone. Plus you're using lots of > > > > > > > devm_ > > > > > > > already. > > > > > > > > > > > > Good point, so I just checked and the vboxvideo code is already > > > > > > using pcim_enable_device() so it looks like this is a false-positive > > > > > > from the l...@intel.com bot, and Dan Carpenter missed that > > > > > > pcim_enable_device() > > > > > > makes all subsequent pci-resource acquiring calls behave like devm > > > > > > calls, > > > > > > when he forwarded the report to me. > > > > > > > > > > > > Tl;DR: there is no bug / leak and this patch can be dropped. > > > > > > > > > > > > Is there a place where I can report a bug against the > > > > > > l...@intel.com bot > > > > > > for this false-positive ? > > > > > > > > > > Ah. Thanks! > > > > > > > > > > This is a Smatch bug. There is a list for that sma...@vger.kernel.org > > > > > but I already remove the pci_iomap() from the list of functions that > > > > > needs to be unwound based on your report. > > > > > > > > I guess if smatch sees a pci_enable_device but not pcim_enable_device > > > > on the same device as passed to pci_iomap (and a pile of other pci > > > > functions) then it still must be unwound. Could smatch detect that? > > > > There's a lot of pci drivers not using the managed functions, catching > > > > bugs in these would be good. > > > > > > It's a lot of code. There would be two ways to implement this: > > > > > > 1) Somehow store the links to figure out the value of: > > > > > > devres_find(vbox->ddev.pdev.dev)->enabled > > > > > > That's very complicated. I'm sort of working on some of the steps > > > involved but and it's probably a multi year process before it's > > > possible. > > > > > > 2) Create a data base table with driver data, then store if the driver > > > calls pcim_enable_device(). This is still a bit of work, but probably > > > straight forward. Storing driver data would be useful for other things > > > as well. > > > > Hm maybe I totally misunderstand how smatch works, but I thought you > > can track additional invariants and stuff on various pointers. So I > > figured you just track whether pci_enable_device has been called on a > > struct pci_device *dev, and then if anyone calls pci_iomap on the same > > pointer and there's no cleanup, it's a bug. For any other case you > > just can't tell (since absence of pcim_enable_device might just mean > > that smatch doesn't see through the maze). Or is that what you meant > > with approach 2? > > Hm... Your idea is another option #3. It's probably less work. > > I'll take a look at it. btw if you do this, the inverse isn't an issue. I.e. a pcim_enable_device on the same pci_device you see a pci_iounmap. This can happen when a driver maps something just to check a few things, reliazes the feature isn't there, and then drops the mapping. It's only redundant when it's on a direct return path of the driver's pci_driver->probe function, or anything that's only called from pci_driver->remove. So quite tricky to correctly catch all cases. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Fri, Nov 20, 2020 at 10:39:45AM +0100, Daniel Vetter wrote: > On Fri, Nov 20, 2020 at 8:58 AM Dan Carpenter > wrote: > > > > On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote: > > > On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter > > > wrote: > > > > > > > > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote: > > > > > Hi, > > > > > > > > > > On 10/27/20 2:51 PM, Hans de Goede wrote: > > > > > > Add missing pci_iounmap() calls to properly unmap the memory on > > > > > > probe-failure and remove. > > > > > > > > > > > > Reported-by: kernel test robot > > > > > > Reported-by: Dan Carpenter > > > > > > Signed-off-by: Hans de Goede > > > > > > > > > > For some reason the spam-filter used by Red Hat's email system has > > > > > eaten > > > > > Daniel Vetter's reply to this, so let me copy and paste that from > > > > > patchwork: > > > > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > I think switching over to devm would be really nice. And for pci all > > > > > > you need to do is use pcim_enable_device and delete all the cleanup > > > > > > code, and it's all done. Hand rolling device cleanup code really > > > > > > isn't > > > > > > a great idea and way too error-prone. Plus you're using lots of > > > > > > devm_ > > > > > > already. > > > > > > > > > > Good point, so I just checked and the vboxvideo code is already > > > > > using pcim_enable_device() so it looks like this is a false-positive > > > > > from the l...@intel.com bot, and Dan Carpenter missed that > > > > > pcim_enable_device() > > > > > makes all subsequent pci-resource acquiring calls behave like devm > > > > > calls, > > > > > when he forwarded the report to me. > > > > > > > > > > Tl;DR: there is no bug / leak and this patch can be dropped. > > > > > > > > > > Is there a place where I can report a bug against the l...@intel.com > > > > > bot > > > > > for this false-positive ? > > > > > > > > Ah. Thanks! > > > > > > > > This is a Smatch bug. There is a list for that sma...@vger.kernel.org > > > > but I already remove the pci_iomap() from the list of functions that > > > > needs to be unwound based on your report. > > > > > > I guess if smatch sees a pci_enable_device but not pcim_enable_device > > > on the same device as passed to pci_iomap (and a pile of other pci > > > functions) then it still must be unwound. Could smatch detect that? > > > There's a lot of pci drivers not using the managed functions, catching > > > bugs in these would be good. > > > > It's a lot of code. There would be two ways to implement this: > > > > 1) Somehow store the links to figure out the value of: > > > > devres_find(vbox->ddev.pdev.dev)->enabled > > > > That's very complicated. I'm sort of working on some of the steps > > involved but and it's probably a multi year process before it's > > possible. > > > > 2) Create a data base table with driver data, then store if the driver > > calls pcim_enable_device(). This is still a bit of work, but probably > > straight forward. Storing driver data would be useful for other things > > as well. > > Hm maybe I totally misunderstand how smatch works, but I thought you > can track additional invariants and stuff on various pointers. So I > figured you just track whether pci_enable_device has been called on a > struct pci_device *dev, and then if anyone calls pci_iomap on the same > pointer and there's no cleanup, it's a bug. For any other case you > just can't tell (since absence of pcim_enable_device might just mean > that smatch doesn't see through the maze). Or is that what you meant > with approach 2? Hm... Your idea is another option #3. It's probably less work. I'll take a look at it. regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Fri, Nov 20, 2020 at 8:58 AM Dan Carpenter wrote: > > On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote: > > On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter > > wrote: > > > > > > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote: > > > > Hi, > > > > > > > > On 10/27/20 2:51 PM, Hans de Goede wrote: > > > > > Add missing pci_iounmap() calls to properly unmap the memory on > > > > > probe-failure and remove. > > > > > > > > > > Reported-by: kernel test robot > > > > > Reported-by: Dan Carpenter > > > > > Signed-off-by: Hans de Goede > > > > > > > > For some reason the spam-filter used by Red Hat's email system has eaten > > > > Daniel Vetter's reply to this, so let me copy and paste that from > > > > patchwork: > > > > > > > > Daniel Vetter wrote: > > > > > > > > > I think switching over to devm would be really nice. And for pci all > > > > > you need to do is use pcim_enable_device and delete all the cleanup > > > > > code, and it's all done. Hand rolling device cleanup code really isn't > > > > > a great idea and way too error-prone. Plus you're using lots of devm_ > > > > > already. > > > > > > > > Good point, so I just checked and the vboxvideo code is already > > > > using pcim_enable_device() so it looks like this is a false-positive > > > > from the l...@intel.com bot, and Dan Carpenter missed that > > > > pcim_enable_device() > > > > makes all subsequent pci-resource acquiring calls behave like devm > > > > calls, > > > > when he forwarded the report to me. > > > > > > > > Tl;DR: there is no bug / leak and this patch can be dropped. > > > > > > > > Is there a place where I can report a bug against the l...@intel.com bot > > > > for this false-positive ? > > > > > > Ah. Thanks! > > > > > > This is a Smatch bug. There is a list for that sma...@vger.kernel.org > > > but I already remove the pci_iomap() from the list of functions that > > > needs to be unwound based on your report. > > > > I guess if smatch sees a pci_enable_device but not pcim_enable_device > > on the same device as passed to pci_iomap (and a pile of other pci > > functions) then it still must be unwound. Could smatch detect that? > > There's a lot of pci drivers not using the managed functions, catching > > bugs in these would be good. > > It's a lot of code. There would be two ways to implement this: > > 1) Somehow store the links to figure out the value of: > > devres_find(vbox->ddev.pdev.dev)->enabled > > That's very complicated. I'm sort of working on some of the steps > involved but and it's probably a multi year process before it's > possible. > > 2) Create a data base table with driver data, then store if the driver > calls pcim_enable_device(). This is still a bit of work, but probably > straight forward. Storing driver data would be useful for other things > as well. Hm maybe I totally misunderstand how smatch works, but I thought you can track additional invariants and stuff on various pointers. So I figured you just track whether pci_enable_device has been called on a struct pci_device *dev, and then if anyone calls pci_iomap on the same pointer and there's no cleanup, it's a bug. For any other case you just can't tell (since absence of pcim_enable_device might just mean that smatch doesn't see through the maze). Or is that what you meant with approach 2? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote: > On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter > wrote: > > > > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote: > > > Hi, > > > > > > On 10/27/20 2:51 PM, Hans de Goede wrote: > > > > Add missing pci_iounmap() calls to properly unmap the memory on > > > > probe-failure and remove. > > > > > > > > Reported-by: kernel test robot > > > > Reported-by: Dan Carpenter > > > > Signed-off-by: Hans de Goede > > > > > > For some reason the spam-filter used by Red Hat's email system has eaten > > > Daniel Vetter's reply to this, so let me copy and paste that from > > > patchwork: > > > > > > Daniel Vetter wrote: > > > > > > > I think switching over to devm would be really nice. And for pci all > > > > you need to do is use pcim_enable_device and delete all the cleanup > > > > code, and it's all done. Hand rolling device cleanup code really isn't > > > > a great idea and way too error-prone. Plus you're using lots of devm_ > > > > already. > > > > > > Good point, so I just checked and the vboxvideo code is already > > > using pcim_enable_device() so it looks like this is a false-positive > > > from the l...@intel.com bot, and Dan Carpenter missed that > > > pcim_enable_device() > > > makes all subsequent pci-resource acquiring calls behave like devm calls, > > > when he forwarded the report to me. > > > > > > Tl;DR: there is no bug / leak and this patch can be dropped. > > > > > > Is there a place where I can report a bug against the l...@intel.com bot > > > for this false-positive ? > > > > Ah. Thanks! > > > > This is a Smatch bug. There is a list for that sma...@vger.kernel.org > > but I already remove the pci_iomap() from the list of functions that > > needs to be unwound based on your report. > > I guess if smatch sees a pci_enable_device but not pcim_enable_device > on the same device as passed to pci_iomap (and a pile of other pci > functions) then it still must be unwound. Could smatch detect that? > There's a lot of pci drivers not using the managed functions, catching > bugs in these would be good. It's a lot of code. There would be two ways to implement this: 1) Somehow store the links to figure out the value of: devres_find(vbox->ddev.pdev.dev)->enabled That's very complicated. I'm sort of working on some of the steps involved but and it's probably a multi year process before it's possible. 2) Create a data base table with driver data, then store if the driver calls pcim_enable_device(). This is still a bit of work, but probably straight forward. Storing driver data would be useful for other things as well. regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter wrote: > > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote: > > Hi, > > > > On 10/27/20 2:51 PM, Hans de Goede wrote: > > > Add missing pci_iounmap() calls to properly unmap the memory on > > > probe-failure and remove. > > > > > > Reported-by: kernel test robot > > > Reported-by: Dan Carpenter > > > Signed-off-by: Hans de Goede > > > > For some reason the spam-filter used by Red Hat's email system has eaten > > Daniel Vetter's reply to this, so let me copy and paste that from patchwork: > > > > Daniel Vetter wrote: > > > > > I think switching over to devm would be really nice. And for pci all > > > you need to do is use pcim_enable_device and delete all the cleanup > > > code, and it's all done. Hand rolling device cleanup code really isn't > > > a great idea and way too error-prone. Plus you're using lots of devm_ > > > already. > > > > Good point, so I just checked and the vboxvideo code is already > > using pcim_enable_device() so it looks like this is a false-positive > > from the l...@intel.com bot, and Dan Carpenter missed that > > pcim_enable_device() > > makes all subsequent pci-resource acquiring calls behave like devm calls, > > when he forwarded the report to me. > > > > Tl;DR: there is no bug / leak and this patch can be dropped. > > > > Is there a place where I can report a bug against the l...@intel.com bot > > for this false-positive ? > > Ah. Thanks! > > This is a Smatch bug. There is a list for that sma...@vger.kernel.org > but I already remove the pci_iomap() from the list of functions that > needs to be unwound based on your report. I guess if smatch sees a pci_enable_device but not pcim_enable_device on the same device as passed to pci_iomap (and a pile of other pci functions) then it still must be unwound. Could smatch detect that? There's a lot of pci drivers not using the managed functions, catching bugs in these would be good. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote: > Hi, > > On 10/27/20 2:51 PM, Hans de Goede wrote: > > Add missing pci_iounmap() calls to properly unmap the memory on > > probe-failure and remove. > > > > Reported-by: kernel test robot > > Reported-by: Dan Carpenter > > Signed-off-by: Hans de Goede > > For some reason the spam-filter used by Red Hat's email system has eaten > Daniel Vetter's reply to this, so let me copy and paste that from patchwork: > > Daniel Vetter wrote: > > > I think switching over to devm would be really nice. And for pci all > > you need to do is use pcim_enable_device and delete all the cleanup > > code, and it's all done. Hand rolling device cleanup code really isn't > > a great idea and way too error-prone. Plus you're using lots of devm_ > > already. > > Good point, so I just checked and the vboxvideo code is already > using pcim_enable_device() so it looks like this is a false-positive > from the l...@intel.com bot, and Dan Carpenter missed that > pcim_enable_device() > makes all subsequent pci-resource acquiring calls behave like devm calls, > when he forwarded the report to me. > > Tl;DR: there is no bug / leak and this patch can be dropped. > > Is there a place where I can report a bug against the l...@intel.com bot > for this false-positive ? Ah. Thanks! This is a Smatch bug. There is a list for that sma...@vger.kernel.org but I already remove the pci_iomap() from the list of functions that needs to be unwound based on your report. regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
Hi,
On 10/27/20 2:51 PM, Hans de Goede wrote:
> Add missing pci_iounmap() calls to properly unmap the memory on
> probe-failure and remove.
>
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Hans de Goede
For some reason the spam-filter used by Red Hat's email system has eaten
Daniel Vetter's reply to this, so let me copy and paste that from patchwork:
Daniel Vetter wrote:
> I think switching over to devm would be really nice. And for pci all
> you need to do is use pcim_enable_device and delete all the cleanup
> code, and it's all done. Hand rolling device cleanup code really isn't
> a great idea and way too error-prone. Plus you're using lots of devm_
> already.
Good point, so I just checked and the vboxvideo code is already
using pcim_enable_device() so it looks like this is a false-positive
from the l...@intel.com bot, and Dan Carpenter missed that pcim_enable_device()
makes all subsequent pci-resource acquiring calls behave like devm calls,
when he forwarded the report to me.
Tl;DR: there is no bug / leak and this patch can be dropped.
Is there a place where I can report a bug against the l...@intel.com bot
for this false-positive ?
Regards,
Hans
> ---
> drivers/gpu/drm/vboxvideo/vbox_main.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
> b/drivers/gpu/drm/vboxvideo/vbox_main.c
> index d68d9bad7674..2eeb1d3be54a 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_main.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
> @@ -71,6 +71,8 @@ static void vbox_accel_fini(struct vbox_private *vbox)
>
> for (i = 0; i < vbox->num_crtcs; ++i)
> vbva_disable(&vbox->vbva_info[i], vbox->guest_pool, i);
> +
> + pci_iounmap(vbox->ddev.pdev, vbox->vbva_buffers);
> }
>
> /* Do we support the 4.3 plus mode hint reporting interface? */
> @@ -124,19 +126,19 @@ int vbox_hw_init(struct vbox_private *vbox)
> vbox->guest_pool = devm_gen_pool_create(vbox->ddev.dev, 4, -1,
> "vboxvideo-accel");
> if (!vbox->guest_pool)
> - return -ENOMEM;
> + goto out_unmap_guest_heap;
>
> ret = gen_pool_add_virt(vbox->guest_pool,
> (unsigned long)vbox->guest_heap,
> GUEST_HEAP_OFFSET(vbox),
> GUEST_HEAP_USABLE_SIZE, -1);
> if (ret)
> - return ret;
> + goto out_unmap_guest_heap;
>
> ret = hgsmi_test_query_conf(vbox->guest_pool);
> if (ret) {
> DRM_ERROR("vboxvideo: hgsmi_test_query_conf failed\n");
> - return ret;
> + goto out_unmap_guest_heap;
> }
>
> /* Reduce available VRAM size to reflect the guest heap. */
> @@ -148,23 +150,30 @@ int vbox_hw_init(struct vbox_private *vbox)
>
> if (!have_hgsmi_mode_hints(vbox)) {
> ret = -ENOTSUPP;
> - return ret;
> + goto out_unmap_guest_heap;
> }
>
> vbox->last_mode_hints = devm_kcalloc(vbox->ddev.dev, vbox->num_crtcs,
>sizeof(struct vbva_modehint),
>GFP_KERNEL);
> - if (!vbox->last_mode_hints)
> - return -ENOMEM;
> + if (!vbox->last_mode_hints) {
> + ret = -ENOMEM;
> + goto out_unmap_guest_heap;
> + }
>
> ret = vbox_accel_init(vbox);
> if (ret)
> - return ret;
> + goto out_unmap_guest_heap;
>
> return 0;
> +
> +out_unmap_guest_heap:
> + pci_iounmap(vbox->ddev.pdev, vbox->guest_pool);
> + return ret;
> }
>
> void vbox_hw_fini(struct vbox_private *vbox)
> {
> vbox_accel_fini(vbox);
> + pci_iounmap(vbox->ddev.pdev, vbox->guest_pool);
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Unmap iomem on probe-failure and remove
On Tue, Oct 27, 2020 at 2:52 PM Hans de Goede wrote:
>
> Add missing pci_iounmap() calls to properly unmap the memory on
> probe-failure and remove.
>
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Hans de Goede
I think switching over to devm would be really nice. And for pci all
you need to do is use pcim_enable_device and delete all the cleanup
code, and it's all done. Hand rolling device cleanup code really isn't
a great idea and way too error-prone. Plus you're using lots of devm_
already.
-Daniel
> ---
> drivers/gpu/drm/vboxvideo/vbox_main.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
> b/drivers/gpu/drm/vboxvideo/vbox_main.c
> index d68d9bad7674..2eeb1d3be54a 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_main.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
> @@ -71,6 +71,8 @@ static void vbox_accel_fini(struct vbox_private *vbox)
>
> for (i = 0; i < vbox->num_crtcs; ++i)
> vbva_disable(&vbox->vbva_info[i], vbox->guest_pool, i);
> +
> + pci_iounmap(vbox->ddev.pdev, vbox->vbva_buffers);
> }
>
> /* Do we support the 4.3 plus mode hint reporting interface? */
> @@ -124,19 +126,19 @@ int vbox_hw_init(struct vbox_private *vbox)
> vbox->guest_pool = devm_gen_pool_create(vbox->ddev.dev, 4, -1,
> "vboxvideo-accel");
> if (!vbox->guest_pool)
> - return -ENOMEM;
> + goto out_unmap_guest_heap;
>
> ret = gen_pool_add_virt(vbox->guest_pool,
> (unsigned long)vbox->guest_heap,
> GUEST_HEAP_OFFSET(vbox),
> GUEST_HEAP_USABLE_SIZE, -1);
> if (ret)
> - return ret;
> + goto out_unmap_guest_heap;
>
> ret = hgsmi_test_query_conf(vbox->guest_pool);
> if (ret) {
> DRM_ERROR("vboxvideo: hgsmi_test_query_conf failed\n");
> - return ret;
> + goto out_unmap_guest_heap;
> }
>
> /* Reduce available VRAM size to reflect the guest heap. */
> @@ -148,23 +150,30 @@ int vbox_hw_init(struct vbox_private *vbox)
>
> if (!have_hgsmi_mode_hints(vbox)) {
> ret = -ENOTSUPP;
> - return ret;
> + goto out_unmap_guest_heap;
> }
>
> vbox->last_mode_hints = devm_kcalloc(vbox->ddev.dev, vbox->num_crtcs,
> sizeof(struct vbva_modehint),
> GFP_KERNEL);
> - if (!vbox->last_mode_hints)
> - return -ENOMEM;
> + if (!vbox->last_mode_hints) {
> + ret = -ENOMEM;
> + goto out_unmap_guest_heap;
> + }
>
> ret = vbox_accel_init(vbox);
> if (ret)
> - return ret;
> + goto out_unmap_guest_heap;
>
> return 0;
> +
> +out_unmap_guest_heap:
> + pci_iounmap(vbox->ddev.pdev, vbox->guest_pool);
> + return ret;
> }
>
> void vbox_hw_fini(struct vbox_private *vbox)
> {
> vbox_accel_fini(vbox);
> + pci_iounmap(vbox->ddev.pdev, vbox->guest_pool);
> }
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
