linux-kernel - Re: [PATCH 04/20] drm/fourcc: Pass the format_info pointer to drm_format_plane

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]

Date:   Wed, 17 Apr 2019 15:12:56 +0200
From:   Maxime Ripard <maxime.ripard@...tlin.com>
To:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Sean Paul <seanpaul@...omium.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org,
        Emil Velikov <emil.velikov@...labora.com>
Subject: Re: [PATCH 04/20] drm/fourcc: Pass the format_info pointer to
 drm_format_plane_width/height

On Wed, Apr 17, 2019 at 01:10:33PM +0200, Maarten Lankhorst wrote:
> Op 17-04-2019 om 13:01 schreef Maxime Ripard:
> > On Wed, Apr 17, 2019 at 12:47:48PM +0200, Maarten Lankhorst wrote:
> >>> +/**
> >>> + * drm_format_info_plane_width - width of the plane given the first plane
> >>> + * @format: pixel format info
> >>> + * @width: width of the first plane
> >>> + * @plane: plane index
> >>> + *
> >>> + * Returns:
> >>> + * The width of @plane, given that the width of the first plane is @width.
> >>> + */
> >>> +static inline
> >>> +int drm_format_info_plane_width(const struct drm_format_info *info, int width,
> >>> +				int plane)
> >>> +{
> >>> +	if (!info || plane >= info->num_planes)
> >>> +		return 0;
> >>> +
> >>> +	if (plane == 0)
> >>> +		return width;
> >>> +
> >>> +	return width / info->hsub;
> >>> +}
> >>> +
> >>> +/**
> >>> + * drm_format_info_plane_height - height of the plane given the first plane
> >>> + * @format: pixel format info
> >>> + * @height: height of the first plane
> >>> + * @plane: plane index
> >>> + *
> >>> + * Returns:
> >>> + * The height of @plane, given that the height of the first plane is @height.
> >>> + */
> >>> +static inline
> >>> +int drm_format_info_plane_height(const struct drm_format_info *info, int height,
> >>> +				 int plane)
> >>> +{
> >>> +	if (!info || plane >= info->num_planes)
> >>> +		return 0;
> >>> +
> >>> +	if (plane == 0)
> >>> +		return height;
> >>> +
> >>> +	return height / info->vsub;
> >>> +}
> >> Why the null checks? None of the other inlines for drm_format_info
> >> perform them.
> > Unless I'm mistaken, the subsampling only applies to the planes with
> > the chrominance, which are always >= 1. Therefore the plane 0 is
> > always the luminance, to which the subsampling doesn't apply.
> >
> > Or are you talking about something else?
>
>
> The info == NULL check. :)

Aaah, sorry :)

That's true, and that's actually the first four patches that change
that behaviour a bit. Previously, drm_format_plane_cpp, _width, and
_height will do the lookup themselves using drm_format_info, and test
whether the pointer returned is null or not.

Patches 3 and 4 removed that lookup but kept the null pointer check.

We could remove it, but there's two downsides for that:

  * since the lookup is now effectively pushed to the caller (or the
    caller's caller), we would have to check there that the pointer isn't
    NULL. That's a lot of boilerplate to add.

  * And since this is a generic function, I wouldn't trust the caller
    to give a pointer that can be dereferenced right away. This might
    be more subjective though.

So I guess we should make sure that we are consistent, but I'd be in
favor of putting that check in all the functions.

Maxime

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

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