All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: Use kvzalloc for allocating blob property memory
Date: Fri, 29 Jun 2018 19:12:05 +0300	[thread overview]
Message-ID: <20180629161205.GE5565@intel.com> (raw)
In-Reply-To: <20180629142710.2069-1-michel@daenzer.net>

On Fri, Jun 29, 2018 at 04:27:10PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daenzer@amd.com>
> 
> The property size may be controlled by userspace, can be large (I've
> seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be
> physically contiguous.

I wonder if we should enforce some kind of reasonable limit
on the blob size. Looks like we allow anything up to
ULONG_MAX currently. We can't tell at createblob time how
the thing is going to be used, so can't have any kind
of property specific limit unfortunately.

> 
> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
> ---
>  drivers/gpu/drm/drm_property.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 1f8031e30f53..cdb10f885a4f 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -532,7 +532,7 @@ static void drm_property_free_blob(struct kref *kref)
>  
>  	drm_mode_object_unregister(blob->dev, &blob->base);
>  
> -	kfree(blob);
> +	kvfree(blob);
>  }
>  
>  /**
> @@ -559,7 +559,7 @@ drm_property_create_blob(struct drm_device *dev, size_t length,
>  	if (!length || length > ULONG_MAX - sizeof(struct drm_property_blob))
>  		return ERR_PTR(-EINVAL);
>  
> -	blob = kzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
> +	blob = kvzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
>  	if (!blob)
>  		return ERR_PTR(-ENOMEM);
>  
> @@ -576,7 +576,7 @@ drm_property_create_blob(struct drm_device *dev, size_t length,
>  	ret = __drm_mode_object_add(dev, &blob->base, DRM_MODE_OBJECT_BLOB,
>  				    true, drm_property_free_blob);
>  	if (ret) {
> -		kfree(blob);
> +		kvfree(blob);
>  		return ERR_PTR(-EINVAL);
>  	}
>  
> -- 
> 2.18.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: Gustavo Padovan <gustavo@padovan.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Sean Paul <seanpaul@chromium.org>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: Use kvzalloc for allocating blob property memory
Date: Fri, 29 Jun 2018 19:12:05 +0300	[thread overview]
Message-ID: <20180629161205.GE5565@intel.com> (raw)
In-Reply-To: <20180629142710.2069-1-michel@daenzer.net>

On Fri, Jun 29, 2018 at 04:27:10PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daenzer@amd.com>
> 
> The property size may be controlled by userspace, can be large (I've
> seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be
> physically contiguous.

I wonder if we should enforce some kind of reasonable limit
on the blob size. Looks like we allow anything up to
ULONG_MAX currently. We can't tell at createblob time how
the thing is going to be used, so can't have any kind
of property specific limit unfortunately.

> 
> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
> ---
>  drivers/gpu/drm/drm_property.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 1f8031e30f53..cdb10f885a4f 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -532,7 +532,7 @@ static void drm_property_free_blob(struct kref *kref)
>  
>  	drm_mode_object_unregister(blob->dev, &blob->base);
>  
> -	kfree(blob);
> +	kvfree(blob);
>  }
>  
>  /**
> @@ -559,7 +559,7 @@ drm_property_create_blob(struct drm_device *dev, size_t length,
>  	if (!length || length > ULONG_MAX - sizeof(struct drm_property_blob))
>  		return ERR_PTR(-EINVAL);
>  
> -	blob = kzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
> +	blob = kvzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
>  	if (!blob)
>  		return ERR_PTR(-ENOMEM);
>  
> @@ -576,7 +576,7 @@ drm_property_create_blob(struct drm_device *dev, size_t length,
>  	ret = __drm_mode_object_add(dev, &blob->base, DRM_MODE_OBJECT_BLOB,
>  				    true, drm_property_free_blob);
>  	if (ret) {
> -		kfree(blob);
> +		kvfree(blob);
>  		return ERR_PTR(-EINVAL);
>  	}
>  
> -- 
> 2.18.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2018-06-29 16:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 14:27 [PATCH] drm: Use kvzalloc for allocating blob property memory Michel Dänzer
2018-06-29 14:27 ` Michel Dänzer
2018-06-29 14:50 ` Alex Deucher
2018-06-29 14:50   ` Alex Deucher
2018-06-29 16:12 ` Ville Syrjälä [this message]
2018-06-29 16:12   ` Ville Syrjälä
2018-06-29 16:27   ` Michel Dänzer
2018-06-29 16:27     ` Michel Dänzer
2018-06-29 16:38     ` Ville Syrjälä
2018-06-29 16:38       ` Ville Syrjälä
2018-07-02  8:07       ` Daniel Vetter
2018-07-02  8:07         ` Daniel Vetter

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=20180629161205.GE5565@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.