From: Lucas Stach <l.stach@pengutronix.de>
To: Paul Cercueil <paul@crapouillou.net>,
Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: David Airlie <airlied@linux.ie>,
The etnaviv authors <etnaviv@lists.freedesktop.org>,
stable@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
DRI mailing list <dri-devel@lists.freedesktop.org>,
Russell King <linux+etnaviv@armlinux.org.uk>
Subject: Re: [PATCH] drm/etnaviv: fix perfmon domain interation
Date: Fri, 15 May 2020 12:24:47 +0200 [thread overview]
Message-ID: <a51cb70623c4c2441bb8df8385f56c99392b8435.camel@pengutronix.de> (raw)
In-Reply-To: <X0BDAQ.L99CTJZCDEJE3@crapouillou.net>
Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> Hi Christian,
>
> Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> <christian.gmeiner@gmail.com> a écrit :
> > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > <christian.gmeiner@gmail.com>:
> > > The GC860 has one GPU device which has a 2d and 3d core. In this
> > > case
> > > we want to expose perfmon information for both cores.
> > >
> > > The driver has one array which contains all possible perfmon domains
> > > with some meta data - doms_meta. Here we can see that for the GC860
> > > two elements of that array are relevant:
> > >
> > > doms_3d: is at index 0 in the doms_meta array with 8 perfmon
> > > domains
> > > doms_2d: is at index 1 in the doms_meta array with 1 perfmon
> > > domain
> > >
> > > The userspace driver wants to get a list of all perfmon domains and
> > > their perfmon signals. This is done by iterating over all domains
> > > and
> > > their signals. If the userspace driver wants to access the domain
> > > with
> > > id 8 the kernel driver fails and returns invalid data from doms_3d
> > > with
> > > and invalid offset.
> > >
> > > This results in:
> > > Unable to handle kernel paging request at virtual address 00000000
> > >
> > > On such a device it is not possible to use the userspace driver at
> > > all.
> > >
> > > The fix for this off-by-one error is quite simple.
> > >
> > > Reported-by: Paul Cercueil <paul@crapouillou.net>
> > > Tested-by: Paul Cercueil <paul@crapouillou.net>
> > > Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query
> > > infrastructure")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
> > > ---
> > > drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > index e6795bafcbb9..35f7171e779a 100644
> > > --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > @@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain
> > > *pm_domain(const struct etnaviv_gpu *gpu,
> > > if (!(gpu->identity.features & meta->feature))
> > > continue;
> > >
> > > - if (meta->nr_domains < (index - offset)) {
> > > + if ((meta->nr_domains - 1) < (index - offset)) {
> > > offset += meta->nr_domains;
> > > continue;
> > > }
> > > --
> > > 2.26.2
> > >
> >
> > ping
>
> I'll merge it tomorrow if there's no further feedback.
Huh? Etnaviv patches are going through the etnaviv tree.
We now have two different solutions to the same issue. I first want to
dig into the code to see why two developers can get confused enough by
the code to come up with totally different fixes.
Regards,
Lucas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-05-15 10:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 12:38 [PATCH] drm/etnaviv: fix perfmon domain interation Christian Gmeiner
2020-05-15 10:09 ` Christian Gmeiner
2020-05-15 10:12 ` Paul Cercueil
2020-05-15 10:24 ` Lucas Stach [this message]
2020-05-15 10:27 ` Christian Gmeiner
2020-05-15 10:33 ` Lucas Stach
2020-05-15 10:44 ` Christian Gmeiner
2020-05-15 10:26 ` Christian Gmeiner
-- strict thread matches above, loose matches on Subject: below --
2020-05-11 12:37 Christian Gmeiner
2020-05-17 12:03 ` Lucas Stach
2020-05-18 8:49 ` Christian Gmeiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a51cb70623c4c2441bb8df8385f56c99392b8435.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=airlied@linux.ie \
--cc=christian.gmeiner@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@crapouillou.net \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).