[Mesa-dev] Fwd: New Defects reported by Coverity Scan for Mesa

[Lionel Landwerlin]

On 16/11/16 01:35, Jordan Justen wrote:
> On 2016-11-15 16:21:27, Matt Turner wrote:
>> Jordan,
>>
>> In
>>
>> commit 0041169cacb300a882b4dc38cd341f98bf2a7c38
>> Author: Jordan Justen <jordan.l.justen at intel.com>
>> Date:   Fri Oct 21 12:56:49 2016 +0100
>>
> This date is not correct. In my branch it was:
>
> Date: Mon Jun 30 00:50:56 2014 +0000

Yeah, because cherry-pick turned out to be more painful than rewriting 
the patch with --author.

>
> I wonder how the date got reset... Nevertheless, the newest version I
> have in my old branch also seems to have the bugs you describe.
>
> Anyway, Lionel pushed this patch and some others for aux-hiz support.
> It looks like he also has a "i965: miptree: prevent potential NULL
> pointer access" follow up patch to address this issue.

I'll push this right now.

> Do we have a bugzilla for it?
>
> -Jordan
>
>>      i965: Wrap MCS miptree in intel_miptree_aux_buffer
>>
>> you changed intel_miptree_alloc_mcs() to return mt->mcs_buf != NULL.
>>
>> mt->mcs_buf is assigned a few lines higher the result of
>> intel_mcs_miptree_buf_create(), which may return NULL. Then, inside
>> intel_miptree_init_mcs(), mt->mcs_buf is unconditionally dereferenced
>> multiple times (and even free()d without setting the pointer to NULL
>> afterwards).
>>
>> This seems very broken.
>>
>> ________________________________________________________________________________________________________
>> *** CID 1394290:  Null pointer dereferences  (REVERSE_INULL)
>> /src/mesa/drivers/dri/i965/intel_mipmap_tree.c: 1610 in
>> intel_miptree_alloc_mcs()
>> 1604                                        mt->logical_width0,
>> 1605                                        mt->logical_height0,
>> 1606                                        MIPTREE_LAYOUT_ACCELERATED_UPLOAD);
>> 1607
>> 1608        intel_miptree_init_mcs(brw, mt, 0xFF);
>> 1609
>>>>>      CID 1394290:  Null pointer dereferences  (REVERSE_INULL)
>>>>>      Null-checking "mt->mcs_buf" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
>> 1610        return mt->mcs_buf != NULL;
>> 1611     }
>> 1612
>> 1613
>> 1614     bool
>> 1615     intel_miptree_alloc_non_msrt_mcs(struct brw_context *brw,