[Intel-gfx] [PATCH 5/6] drm,i915: Introduce drm_malloc_gfp()

Chris Wilson chris at chris-wilson.co.uk
Wed Apr 6 09:47:39 UTC 2016


On Wed, Apr 06, 2016 at 10:40:19AM +0100, Tvrtko Ursulin wrote:
> 
> On 05/04/16 14:05, Chris Wilson wrote:
> >On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote:
> >>I have instances where I want to use drm_malloc_ab() but with a custom
> >>gfp mask. And with those, where I want a temporary allocation, I want to
> >>try a high-order kmalloc() before using a vmalloc().
> >>
> >>So refactor my usage into drm_malloc_gfp().
> >>
> >>Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>Cc: dri-devel at lists.freedesktop.org
> >>Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >>Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >>Acked-by: Dave Airlie <airlied at redhat.com>
> >
> >>+static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
> >>+{
> >>+	if (size != 0 && nmemb > SIZE_MAX / size)
> >>+		return NULL;
> >
> >I know Dave G. has some fancy code to detect when the size parameter is
> >not constant, but one thing I noticed was that gcc would uninline this
> >function and we would lose the constant folding. Is there anything we
> >can do to convince gcc to avoid a div here (other than pure macro)?
> 
> Don't know, apart from maybe _always_inline if it is not considered too big.
> 
> But I wanted to ask, why it is interesting to allow size == 0 ? Why not:
> 
> 	if (size == 0 || nmemb > SIZE_MAX / size)
> 		return NULL;
> 
> ?

Cargo-culting. I guess the only thought was to avoid the div-by-zero and
to fallthrough to returning kmalloc(0) for equivalent behaviour.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the dri-devel mailing list