public inbox for dri-devel@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl
Date: Wed, 5 Sep 2018 16:28:11 +0200	[thread overview]
Message-ID: <20180905142811.GE4929@phenom.ffwll.local> (raw)
In-Reply-To: <20180905102205.5472-1-chris@chris-wilson.co.uk>

On Wed, Sep 05, 2018 at 11:22:05AM +0100, Chris Wilson wrote:
> Since this is handling user provided bpp and depth, we need to sanity
> check and propagate the EINVAL back rather than assume what the insane
> client intended and fill the logs with DRM_ERROR.
> 
> v2: Check both bpp and depth match the builtin pixel format, and
> introduce a canonical DRM_FORMAT_INVALID to reserve 0 against any future
> fourcc.
> 
> Testcase: igt/kms_addfb_basic/legacy-format
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>

I checked a bunch of randomly selected userspace pieces, and if there's
hairy stuff going on then it's mis-selected bpp.
> ---
>  drivers/gpu/drm/drm_fourcc.c      | 33 +++++++++++++++++++++----------
>  drivers/gpu/drm/drm_framebuffer.c |  7 ++++++-
>  include/uapi/drm/drm_fourcc.h     |  3 +++
>  3 files changed, 32 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 35c1e2742c27..d9dadbc43327 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -45,32 +45,45 @@ static char printable_char(int c)
>   */
>  uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
>  {
> -	uint32_t fmt;
> +	uint32_t fmt = DRM_FORMAT_INVALID;
>  
>  	switch (bpp) {
>  	case 8:
> -		fmt = DRM_FORMAT_C8;
> +		if (depth == 0)
> +			fmt = DRM_FORMAT_C8;

Michel Dänzer thinks this should be depth == 8 here. I grepped around in
-modesetting, seems outright not supported. Apparently amd drivers do
support it, and set 8/8. With that addressed:

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>


>  		break;
>  	case 16:
> -		if (depth == 15)
> +		switch (depth) {
> +		case 15:
>  			fmt = DRM_FORMAT_XRGB1555;
> -		else
> +			break;
> +		case 16:
>  			fmt = DRM_FORMAT_RGB565;
> +			break;
> +		default:
> +			break;
> +		}
>  		break;
>  	case 24:
> -		fmt = DRM_FORMAT_RGB888;
> +		if (depth == 24)
> +			fmt = DRM_FORMAT_RGB888;
>  		break;
>  	case 32:
> -		if (depth == 24)
> +		switch (depth) {
> +		case 24:
>  			fmt = DRM_FORMAT_XRGB8888;
> -		else if (depth == 30)
> +			break;
> +		case 30:
>  			fmt = DRM_FORMAT_XRGB2101010;
> -		else
> +			break;
> +		case 32:
>  			fmt = DRM_FORMAT_ARGB8888;
> +			break;
> +		default:
> +			break;
> +		}
>  		break;
>  	default:
> -		DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
> -		fmt = DRM_FORMAT_XRGB8888;
>  		break;
>  	}
>  
> diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> index 781af1d42d76..636f626c5828 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -112,12 +112,17 @@ int drm_mode_addfb(struct drm_device *dev, struct drm_mode_fb_cmd *or,
>  	struct drm_mode_fb_cmd2 r = {};
>  	int ret;
>  
> +	r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
> +	if (r.pixel_format == DRM_FORMAT_INVALID) {
> +		DRM_DEBUG("bad (bpp:%d, depth:%d)\n", or->bpp, or->depth);
> +		return -EINVAL;
> +	}
> +
>  	/* convert to new format and call new ioctl */
>  	r.fb_id = or->fb_id;
>  	r.width = or->width;
>  	r.height = or->height;
>  	r.pitches[0] = or->pitch;
> -	r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
>  	r.handles[0] = or->handle;
>  
>  	if (r.pixel_format == DRM_FORMAT_XRGB2101010 &&
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 2ed46e9ae16a..139632b87181 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -71,6 +71,9 @@ extern "C" {
>  
>  #define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of little endian */
>  
> +/* Reserve 0 for the invalid format specifier */
> +#define DRM_FORMAT_INVALID	0
> +
>  /* color index */
>  #define DRM_FORMAT_C8		fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
>  
> -- 
> 2.19.0.rc1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-09-05 14:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04 20:53 [PATCH] drm: Reject unknown legacy bpp and dpeth for drm_mode_addfb ioctl Chris Wilson
2018-09-04 21:46 ` Daniel Vetter
2018-09-05 10:10   ` Chris Wilson
2018-09-05 10:22 ` [PATCH] drm: Reject unknown legacy bpp and depth " Chris Wilson
2018-09-05 10:29   ` Chris Wilson
2018-09-05 14:28   ` Daniel Vetter [this message]
2018-09-05 15:31   ` [PATCH v3] " Chris Wilson
2018-09-06  7:19     ` Chris Wilson

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=20180905142811.GE4929@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.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