[PATCH v2 1/3] drm/mm: Ensure that the entry is not NULL before extracting rb_node

[Tvrtko Ursulin]

On 23/02/2022 04:35, Kasireddy, Vivek wrote:
> Hi Tvrtko,
> 
>>
>> On 18/02/2022 03:47, Kasireddy, Vivek wrote:
>>> Hi Tvrtko,
>>>
>>>>
>>>> On 17/02/2022 07:50, Vivek Kasireddy wrote:
>>>>> While looking for next holes suitable for an allocation, although,
>>>>> it is highly unlikely, make sure that the DECLARE_NEXT_HOLE_ADDR
>>>>> macro is using a valid node before it extracts the rb_node from it.
>>>>
>>>> Was the need for this just a consequence of insufficient locking in the
>>>> i915 patch?
>>> [Kasireddy, Vivek] Partly, yes; but I figured since we are anyway doing
>>> if (!entry || ..), it makes sense to dereference entry and extract the rb_node
>>> after this check.
>>
>> Unless I am blind I don't see that it makes a difference.
>> "&entry->rb_hole_addr" is taking an address of, which works "fine" is
> [Kasireddy, Vivek] Ah, didn't realize it was the same thing as offsetof().
> 
>> entry is NULL. And does not get past the !entry check for the actual
>> de-reference via RB_EMPTY_NODE. With your patch you move that after the
>> !entry check but still have it in the RB_EMPTY_NODE macro. Again, unless
>> I am blind, I think just drop this patch.
> [Kasireddy, Vivek] Sure; do you want me to send another version with this
> patch dropped? Or, would you be able to just merge the other two from the
> latest version of this series?

Please send without the first patch so we get clean set of CI results.

You can use "--subject-prefix=CI" with git format-patchs and 
--suppress-cc=all with git send-email to avoid spamming people and let 
readers know the re-send is just for the purpose of getting CI results.

Regards,

Tvrtko