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: <CACvgo51WMD5hsyLB5QTriGNwcPmeN4TDjscJV11M3PXFncPHeQ@mail.gmail.com>
Date:   Tue, 2 Apr 2019 10:43:31 +0100
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     Maxime Ripard <maxime.ripard@...tlin.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 Maxime,

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.

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

HTH
Emil