[Intel-gfx] [PATCH] drm/i915: Use kcalloc more

Chris Wilson chris at chris-wilson.co.uk
Thu Sep 19 14:58:09 CEST 2013


On Thu, Sep 19, 2013 at 02:51:10PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2013 at 01:41:53PM +0100, Chris Wilson wrote:
> > On Thu, Sep 19, 2013 at 02:35:42PM +0200, Daniel Vetter wrote:
> > > On Thu, Sep 19, 2013 at 2:30 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > > On Thu, Sep 19, 2013 at 02:06:39PM +0200, Daniel Vetter wrote:
> > > >> No buffer overflows here, but better safe than sorry.
> > > >>
> > > >> v2:
> > > >> - Fixup the sizeof conversion, I've missed the pointer deref (Jani).
> > > >> - Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
> > > >> - Use kmalloc_array for the execbuf fastpath to avoid the memset
> > > >>   (Chris). I've opted to leave all other conversions as-is since they
> > > >>   aren't in a fastpath and dealing with cleared memory instead of
> > > >>   random garbage is just generally nicer.
> > > >
> > > > I still don't agree with this change to kmalloc_array. The code is
> > > > written explicitly such that an invalid buffer_count is reported as
> > > > EINVAL and not ENOMEM.
> > > 
> > > It's just paranoia - imo consistently using kcalloc/kmalloc array
> > > where possible is just safer. Note also that the subtest I've added
> > > explicitly checks for EINVAL, so if we ever botch this it should get
> > > caught.
> > 
> > Paranoia for what? Checking the same thing twice in case the compiler
> > changes it mind?
> 
> The compiler actually removes the 2nd check since it's the same ;-) I just
> like the consisten pattern and cozy feeling that we'll have less to worry
> for potential overflows. I can ditch it if you deem it too offensive.

Having been along this road before, I preferred the explicit checking
that also gets the right return value. The goal here is perform all
sanity checks as early as possible - but I'm not going to fight to move
the cliprects test as cliprects are broken by design.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list