linux-kernel - Re: [PATCH] drm/v3d: Fix PM disable depth imbalance in v3d_platform_drm

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPY8ntAdknutH=OmV1dWPbez1ZqLgaOj-BoQQkZAu0WbhbE6nQ@mail.gmail.com>
Date:   Thu, 6 Jan 2022 11:57:23 +0000
From:   Dave Stevenson <dave.stevenson@...pberrypi.com>
To:     Miaoqian Lin <linmq006@...il.com>
Cc:     Emma Anholt <emma@...olt.net>, David Airlie <airlied@...ux.ie>,
        LKML <linux-kernel@...r.kernel.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Eric Anholt <eric@...olt.net>
Subject: Re: [PATCH] drm/v3d: Fix PM disable depth imbalance in v3d_platform_drm_probe

Thanks for the patch.

On Wed, 5 Jan 2022 at 12:04, Miaoqian Lin <linmq006@...il.com> wrote:
>
> The pm_runtime_enable will increase power disable depth.
> If the probe fails, we should use pm_runtime_disable() to balance
> pm_runtime_enable().
>
> Fixes: 57692c9 ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")
> Signed-off-by: Miaoqian Lin <linmq006@...il.com>
> ---
>  drivers/gpu/drm/v3d/v3d_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
> index bd46396a1ae0..4f293aa733b8 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.c
> +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> @@ -300,6 +300,8 @@ static int v3d_platform_drm_probe(struct platform_device *pdev)
>         v3d_gem_destroy(drm);
>  dma_free:
>         dma_free_wc(dev, 4096, v3d->mmu_scratch, v3d->mmu_scratch_paddr);
> +pm_disable:
> +       pm_runtime_disable(dev);

The dma_alloc_wc is done before the pm_runtime_enable, so the cleanup
should be in the opposite order.
Functionally it makes minimal difference in this case as
pm_runtime_enable can't fail, but could cause confusion/errors should
any other initialisation step be added between the two.

The pm_disable label is also unused so not necessary, however if
reversing the order then renaming dma_free to pm_disable would be
sensible.

  Dave

>         return ret;
>  }

>
> --
> 2.17.1
>