linux-kernel - Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev

Open Source and information security mailing list archives

Date:   Mon, 20 Feb 2017 18:07:10 +0100
From:   Stefan Lengfeld <contact@...fanchrist.eu>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Sean Paul <seanpaul@...omium.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma
 fbdev

Hi Maxime,

sorry, I have missed the discussion about the double buffering/virtual
surface size patch series two weeks ago. My comments about the patch are
inline:

On Wed, Feb 15, 2017 at 05:19:08PM +0100, Maxime Ripard wrote:
> From: Xinliang Liu <xinliang.liu@...aro.org>

Mabye you should take the authorship here. Taking the credit and the
blame, because the patch was heavily modified by you and me. But I don't
really know what the offical police about that is.

> 
> This patch add a config to support to create multi buffer for cma fbdev.
> Such as double buffer and triple buffer.
> 
> Cma fbdev is convient to add a legency fbdev. And still many Android
> devices use fbdev now and at least double buffer is needed for these
> Android devices, so that a buffer flip can be operated. It will need
> some time for Android device vendors to abondon legency fbdev. So multi
> buffer for fbdev is needed.
> 
> Signed-off-by: Xinliang Liu <xinliang.liu@...aro.org>
> [s.christ@...tec.de: Picking patch from
>                      https://lkml.org/lkml/2015/9/14/188]
> Signed-off-by: Stefan Christ <s.christ@...tec.de>
> Signed-off-by: Maxime Ripard <maxime.ripard@...e-electrons.com>

Reviewed-by: Stefan Lengfeld <contact@...fanchrist.eu>

My surname has changed from "Christ" to "Lengfeld" recently. So my
review tag contains the new name.

> ---
>  drivers/gpu/drm/Kconfig         |  9 +++++++++
>  drivers/gpu/drm/drm_fb_helper.c | 10 ++++++++++
>  2 files changed, 19 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index ebfe8404c25f..700c8b8e57a9 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -84,6 +84,15 @@ config DRM_FBDEV_EMULATION
>  
>  	  If in doubt, say "Y".
>  
> +config DRM_FBDEV_OVERALLOC
> +	int "Overallocation of the fbdev buffer"
> +	depends on DRM_FBDEV_EMULATION
> +	default 100
> +	help
> +	  Defines the fbdev buffer overallocation in percent. Default
> +	  is 100. Typical values for double buffering will be 200,
> +	  triple buffering 300.
> +
>  config DRM_LOAD_EDID_FIRMWARE
>  	bool "Allow to specify an EDID data set instead of probing for it"
>  	depends on DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e934b541feea..c6de87abaca8 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -48,6 +48,12 @@ module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
>  MODULE_PARM_DESC(fbdev_emulation,
>  		 "Enable legacy fbdev emulation [default=true]");
>  
> +static int drm_fbdev_overalloc = CONFIG_DRM_FBDEV_OVERALLOC;
> +module_param(drm_fbdev_overalloc, int, 0444);

Maybe the variable should be of type "uint" instead of "int". This would
rule out the negative numbers error case.

> +MODULE_PARM_DESC(drm_fbdev_overalloc,
> +		 "Overallocation of the fbdev buffer (%) [default="
> +		 __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
> +
>  static LIST_HEAD(kernel_fb_helper_list);
>  static DEFINE_MUTEX(kernel_fb_helper_lock);
>  
> @@ -1573,6 +1579,10 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
>  		sizes.fb_height = sizes.surface_height = 768;
>  	}
>  
> +	/* Handle our overallocation */
> +	sizes.surface_height *= drm_fbdev_overalloc;
> +	sizes.surface_height /= 100;
> +

The code can trigger an arithmetic overflow, but I think we can ignore
this error case here.

But there should be a check for drm_fbdev_overalloc not be smaller than
100. If it is smaller, the variable drm_fbdev_overalloc should have the
default value "100". Otherwise the virtual surface height can be smaller
than the physical height. This could trigger a lot of errors in existing
code paths.

Kind regards,
	Stefan Lengfeld

>  	/* push down into drivers */
>  	ret = (*fb_helper->funcs->fb_probe)(fb_helper, &sizes);
>  	if (ret < 0)
> -- 
> git-series 0.8.11
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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