linux-kernel - Re: Adreno devfreq lockdep splat with 6.3-rc2

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: <CAF6AEGsHFpGEiOLxEqzxG2VU+i+h0uVQTHcpfD4sbk0GWN2+Vg@mail.gmail.com>
Date:   Fri, 9 Jun 2023 07:46:44 -0700
From:   Rob Clark <robdclark@...il.com>
To:     Johan Hovold <johan@...nel.org>
Cc:     Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
        freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: Adreno devfreq lockdep splat with 6.3-rc2

On Thu, Jun 8, 2023 at 11:17 PM Johan Hovold <johan@...nel.org> wrote:
>
> On Thu, Jun 08, 2023 at 02:17:45PM -0700, Rob Clark wrote:
> > On Thu, Jun 8, 2023 at 7:12 AM Johan Hovold <johan@...nel.org> wrote:
>
> > > Have you had a chance to look at this regression yet? It prevents us
> > > from using lockdep on the X13s as it is disabled as soon as we start
> > > the GPU.
> >
> > Hmm, curious what is different between x13s and sc7180/sc7280 things?
>
> It seems like lockdep needs to hit the tear down path in order to
> detect the circular lock dependency. Perhaps you don't hit that on your
> sc7180/sc7280?
>
> It is due to the fact that the panel is looked up way too late so that
> bind fails unless the panel driver is already loaded when the msm drm
> driver probes.

Oh, this seems likely

> Manually loading the panel driver before msm makes the splat go away.
>
> > Or did lockdep recently get more clever (or more annotation)?
>
> I think this is indeed a new problem related to some of the devfreq work
> you did in 6.3-rc1 (e.g. fadcc3ab1302 ("drm/msm/gpu: Bypass PM QoS
> constraint for idle clamp")).
>
> > I did spend some time a while back trying to bring some sense to
> > devfreq/pm-qos/icc locking:
> > https://patchwork.freedesktop.org/series/115028/
> >
> > but haven't had time to revisit that for a while
>
> That's the series I link to below, but IIRC it did not look directly
> applicable to the splat I see on X13s (e.g. does not involve
> fs_reclaim).

Ahh, right, sorry I've not had time to do more than glance at the
thread.. and yeah, that one is mostly just trying to solve the reclaim
problem by moving allocations out from under the big-pm-qos-lock.

As far as fadcc3ab1302 ("drm/msm/gpu: Bypass PM QoS constraint for
idle clamp"), it should be just taking the lock that
dev_pm_qos_update_request() would have indirectly, although I guess
without some intervening lock?  We can't really avoid taking the
devfreq lock, I don't think.  But I'd have to spend time I don't have
right now digging into it..

BR,
-R

> > > On Wed, Mar 15, 2023 at 10:19:21AM +0100, Johan Hovold wrote:
> > > >
> > > > Since 6.3-rc2 (or possibly -rc1), I'm now seeing the below
> > > > devfreq-related lockdep splat.
> > > >
> > > > I noticed that you posted a fix for something similar here:
> > > >
> > > >       https://lore.kernel.org/r/20230312204150.1353517-9-robdclark@gmail.com
> > > >
> > > > but that particular patch makes no difference.
> > > >
> > > > From skimming the calltraces below and qos/devfreq related changes in
> > > > 6.3-rc1 it seems like this could be related to:
> > > >
> > > >       fadcc3ab1302 ("drm/msm/gpu: Bypass PM QoS constraint for idle clamp")
>
> Johan