linux-kernel - Re: [RFC PATCH 01/20] drm: Remove users of drm_format_num

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: <20190402145114.bpt5atxxooufgzz5@flea>
Date:   Tue, 2 Apr 2019 16:51:14 +0200
From:   Maxime Ripard <maxime.ripard@...tlin.com>
To:     Emil Velikov <emil.l.velikov@...il.com>
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Sean Paul <seanpaul@...omium.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        linux-media@...r.kernel.org
Subject: Re: [RFC PATCH 01/20] drm: Remove users of drm_format_num_planes

Hi Emil,

On Tue, Apr 02, 2019 at 10:43:31AM +0100, Emil Velikov wrote:
> On Tue, 19 Mar 2019 at 21:57, Maxime Ripard <maxime.ripard@...tlin.com> wrote:
> > drm_format_num_planes() is basically a lookup in the drm_format_info table
> > plus an access to the num_planes field of the appropriate entry.
> >
> > Most drivers are using this function while having access to the entry
> > already, which means that we will perform an unnecessary lookup. Removing
> > the call to drm_format_num_planes is therefore more efficient.
> >
> > Some drivers will not have access to that entry in the function, but in
> > this case the overhead is minimal (we just have to call drm_format_info()
> > to perform the lookup) and we can even avoid multiple, inefficient lookups
> > in some places that need multiple fields from the drm_format_info
> > structure.
> >
>
> I'm not fan of the duplicated loop-ups either.
>
> > -int drm_format_num_planes(uint32_t format)
> > -{
> > -       const struct drm_format_info *info;
> > -
> > -       info = drm_format_info(format);
> > -       return info ? info->num_planes : 1;
> > -}
> > -EXPORT_SYMBOL(drm_format_num_planes);
> > -
>
> The existing users are not updated to cater for the num_planes != 0
> case... Which seems non-existent scenario since all the current format
> descriptions have 1+ planes.
> Should we add a test (alike the ones in 6/20) to ensure, that no entry
> has 0 planes? Is it even worth it or I'm a bit too paranoid?
>
> The above comments apply to 2/20.

I'm not entirely sure what you mean. num_planes is returned as is in
the drm_format_num_planes function and it doesn't check for the
num_planes value itself.

That being said, we could definitely add some more tests to check that
we haven't falling into the situation you describe, since most of the
drivers indeed don't check for that value themselves. But that seems
pretty othorgonal to me?

> With the name suggestions by Paul, patches 1 to 5 (incl.) are:
> Reviewed-by: Emil Velikov <emil.velikov@...labora.com>

Thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)