Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/query: Split out query item checks
Date: Wed, 9 Jan 2019 09:25:49 +0000	[thread overview]
Message-ID: <ee947237-8891-c782-fd61-e0d9e9e4f87f@linux.intel.com> (raw)
In-Reply-To: <20190109075108.16779-1-abdiel.janulgue@linux.intel.com>


On 09/01/2019 07:51, Abdiel Janulgue wrote:
> This simplifies adding new query item objects.
> 
> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
>   drivers/gpu/drm/i915/i915_query.c | 40 ++++++++++++++++++++-----------
>   1 file changed, 26 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
> index cbcb957b7141..b4f26605f617 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -10,12 +10,33 @@
>   #include "i915_query.h"
>   #include <uapi/drm/i915_drm.h>
>   
> +static int init_query_item_check(void* data_ptr, size_t data_sz,

void *ptr

data_ prefix is not ideal since this is not the trailing data but the 
query header. Maybe query_ ?

> +				 u32 total_length,
> +				 struct drm_i915_query_item *query_item)
> +{
> +	if (query_item->length == 0)
> +		return total_length;
> +
> +	if (query_item->length < total_length)
> +		return -EINVAL;
> +
> +	if (copy_from_user(data_ptr, u64_to_user_ptr(query_item->data_ptr),
> +			   data_sz))
> +		return -EFAULT;

Is lost type information a concern with copy_from_user.. let me check.. 
I am not sure TBH.. there seems to be type based object size check in 
there but does it work when indirected via void*?

> +
> +	if (!access_ok(u64_to_user_ptr(query_item->data_ptr),
> +		       total_length))
> +		return -EFAULT;

Kind of OK, but prevents the code for checking the whole user supplied 
buffer in queries which carry the length field. (Engine discovery is one 
of them.) Argument there was why check more than we will write - to 
catch userspace accidentally passing in a smaller buffer than it thinks 
it is passing in. But it is probably not an important enough concern to 
prevent code consolidation.

So I think for me that leaves the question of type safety on the first 
check.

> +
> +	return 0;
> +}
> +
>   static int query_topology_info(struct drm_i915_private *dev_priv,
>   			       struct drm_i915_query_item *query_item)
>   {
>   	const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
>   	struct drm_i915_query_topology_info topo;
> -	u32 slice_length, subslice_length, eu_length, total_length;
> +	u32 ret, slice_length, subslice_length, eu_length, total_length;

int ret;

>   
>   	if (query_item->flags != 0)
>   		return -EINVAL;
> @@ -33,23 +54,14 @@ static int query_topology_info(struct drm_i915_private *dev_priv,
>   
>   	total_length = sizeof(topo) + slice_length + subslice_length + eu_length;
>   
> -	if (query_item->length == 0)
> -		return total_length;
> -
> -	if (query_item->length < total_length)
> -		return -EINVAL;
> -
> -	if (copy_from_user(&topo, u64_to_user_ptr(query_item->data_ptr),
> -			   sizeof(topo)))
> -		return -EFAULT;
> +	ret = init_query_item_check(&topo, sizeof(topo), total_length,
> +				    query_item);
> +	if (ret != 0)
> +		return ret;
>   
>   	if (topo.flags != 0)
>   		return -EINVAL;
>   
> -	if (!access_ok(u64_to_user_ptr(query_item->data_ptr),
> -		       total_length))
> -		return -EFAULT;
> -
>   	memset(&topo, 0, sizeof(topo));
>   	topo.max_slices = sseu->max_slices;
>   	topo.max_subslices = sseu->max_subslices;
> 

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-01-09  9:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09  7:51 [PATCH] drm/i915/query: Split out query item checks Abdiel Janulgue
2019-01-09  8:23 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-01-09  8:52 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-01-09  9:25 ` Tvrtko Ursulin [this message]
2019-01-09  9:35   ` [PATCH] " Chris Wilson
2019-01-16  8:59 ` [PATCH v2] " Abdiel Janulgue
2019-01-16  9:23   ` Tvrtko Ursulin
2019-02-11 17:32   ` [PATCH v3] " Abdiel Janulgue
2019-02-11 17:49     ` Tvrtko Ursulin
2019-02-26 10:34       ` Chris Wilson
2019-01-16 10:31 ` ✓ Fi.CI.BAT: success for drm/i915/query: Split out query item checks (rev2) Patchwork
2019-01-16 12:37 ` ✓ Fi.CI.IGT: " Patchwork
2019-02-11 18:52 ` ✓ Fi.CI.BAT: success for drm/i915/query: Split out query item checks (rev3) Patchwork
2019-02-11 22:54 ` ✓ Fi.CI.IGT: " Patchwork

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=ee947237-8891-c782-fd61-e0d9e9e4f87f@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=abdiel.janulgue@linux.intel.com \
    --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