linux-kernel - Re: [PATCH] drm/msm/devfreq: Fix OPP refcnt leak

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: <CAD=FV=WnTsdU0TzbbFhRzoYtiX6-HG+g=OHiu1LP+tODPGXZKQ@mail.gmail.com>
Date:   Fri, 5 Nov 2021 08:29:23 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Steev Klimaszewski <steev@...i.org>
Cc:     Rob Clark <robdclark@...il.com>, dri-devel@...ts.freedesktop.org,
        linux-arm-msm@...r.kernel.org, freedreno@...ts.freedesktop.org,
        Rob Clark <robdclark@...omium.org>,
        Sean Paul <sean@...rly.run>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/msm/devfreq: Fix OPP refcnt leak

Hi,

On Thu, Nov 4, 2021 at 9:32 PM Steev Klimaszewski <steev@...i.org> wrote:
>
>
> On 11/4/21 5:28 PM, Rob Clark wrote:
> > From: Rob Clark <robdclark@...omium.org>
> >
> > Reported-by: Douglas Anderson <dianders@...omium.org>
> > Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
> > Signed-off-by: Rob Clark <robdclark@...omium.org>
> > ---
> >   drivers/gpu/drm/msm/msm_gpu_devfreq.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> > index d32b729b4616..9bf8600b6eea 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> > +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> > @@ -20,8 +20,6 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq,
> >       struct msm_gpu *gpu = dev_to_gpu(dev);
> >       struct dev_pm_opp *opp;
> >
> > -     opp = devfreq_recommended_opp(dev, freq, flags);
> > -
> >       /*
> >        * If the GPU is idle, devfreq is not aware, so just ignore
> >        * it's requests
> > @@ -31,6 +29,8 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq,
> >               return 0;
> >       }
> >
> > +     opp = devfreq_recommended_opp(dev, freq, flags);
> > +
> >       if (IS_ERR(opp))
> >               return PTR_ERR(opp);
> >
>
> Testing this here on the Lenovo Yoga C630, and I'm starting to see in my
> dmesg output
>
> [   36.337061] devfreq 5000000.gpu: Couldn't update frequency transition
> information.
> [   36.388122] devfreq 5000000.gpu: Couldn't update frequency transition
> information.

Ah, I think this makes sense. We're now storing a frequency which
might not match an actual "opp" and I suppose that we must return it
in some cases.

I guess a simple fix is to still call devfreq_recommended_opp() in the
idle case but just call dev_pm_opp_put() to fix the leak.

-Doug