Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e92219d7-77f7-a40a-39d9-ea7afc5f3687@redhat.com>
Date:   Fri, 7 Jul 2023 14:41:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA
 mappings
Content-Language: en-US
To:     Boris Brezillon <boris.brezillon@collabora.com>
Cc:     airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de,
        mripard@kernel.org, corbet@lwn.net, christian.koenig@amd.com,
        bskeggs@redhat.com, Liam.Howlett@oracle.com,
        matthew.brost@intel.com, alexdeucher@gmail.com, ogabbay@kernel.org,
        bagasdotme@gmail.com, willy@infradead.org, jason@jlekstrand.net,
        dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        Donald Robson <donald.robson@imgtec.com>,
        Dave Airlie <airlied@redhat.com>
References: <20230629222651.3196-1-dakr@redhat.com>
 <20230629222651.3196-3-dakr@redhat.com>
 <20230707130010.1bd5d41b@collabora.com>
From:   Danilo Krummrich <dakr@redhat.com>
Organization: RedHat
In-Reply-To: <20230707130010.1bd5d41b@collabora.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 7/7/23 13:00, Boris Brezillon wrote:
> On Fri, 30 Jun 2023 00:25:18 +0200
> Danilo Krummrich <dakr@redhat.com> wrote:
> 
>> +/**
>> + * drm_gpuva_for_each_va_range - iternator to walk over a range of &drm_gpuvas
>> + * @va__: &drm_gpuva structure to assign to in each iteration step
>> + * @mgr__: &drm_gpuva_manager to walk over
>> + * @start__: starting offset, the first gpuva will overlap this
>> + * @end__: ending offset, the last gpuva will start before this (but may
>> + * overlap)
>> + *
>> + * This iterator walks over all &drm_gpuvas in the &drm_gpuva_manager that lie
>> + * between @start__ and @end__. It is implemented similarly to list_for_each(),
>> + * but is using the &drm_gpuva_manager's internal interval tree to accelerate
>> + * the search for the starting &drm_gpuva, and hence isn't safe against removal
>> + * of elements. It assumes that @end__ is within (or is the upper limit of) the
>> + * &drm_gpuva_manager. This iterator does not skip over the &drm_gpuva_manager's
>> + * @kernel_alloc_node.
>> + */
>> +#define drm_gpuva_for_each_va_range(va__, mgr__, start__, end__) \
>> +	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__)); \
> 
> drm_gpuva_find_first() takes the range size as its last argument, not
> the range end:
> 
> 	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__) - (start__)); \
> 

Good catch! Originally this was

drm_gpuva_it_iter_first(&(mgr)->rb.tree, (start__), (end__) - 1)

but then I changed it since I did not want to expose the interval tree 
functions directly.

> 
>> +	     va__ && (va__->va.addr < (end__)) && \
>> +	     !list_entry_is_head(va__, &(mgr__)->rb.list, rb.entry); \
>> +	     va__ = list_next_entry(va__, rb.entry))
> 
> If you define:
> 
> static inline struct drm_gpuva *
> drm_gpuva_next(struct drm_gpuva *va)
> {
> 	if (va && !list_is_last(&va->rb.entry, &va->mgr->rb.list))
> 		return list_next_entry(va, rb.entry);
> 
> 	return NULL;
> } >
> the for loop becomes a bit more readable:

Yes, it would. However, I don't want it to be confused with 
drm_gpuva_find_next(). Maybe I should rename the latter to something 
like drm_gpuva_find_next_neighbor() then.

> 
> 	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__) - (start__)); \
> 	     va__ && (va__->va.addr < (end__)); \
> 	     va__ = drm_gpuva_next(va__))
> 
>> +
>> +/**
>> + * drm_gpuva_for_each_va_range_safe - iternator to safely walk over a range of
>> + * &drm_gpuvas
>> + * @va__: &drm_gpuva to assign to in each iteration step
>> + * @next__: another &drm_gpuva to use as temporary storage
>> + * @mgr__: &drm_gpuva_manager to walk over
>> + * @start__: starting offset, the first gpuva will overlap this
>> + * @end__: ending offset, the last gpuva will start before this (but may
>> + * overlap)
>> + *
>> + * This iterator walks over all &drm_gpuvas in the &drm_gpuva_manager that lie
>> + * between @start__ and @end__. It is implemented similarly to
>> + * list_for_each_safe(), but is using the &drm_gpuva_manager's internal interval
>> + * tree to accelerate the search for the starting &drm_gpuva, and hence is safe
>> + * against removal of elements. It assumes that @end__ is within (or is the
>> + * upper limit of) the &drm_gpuva_manager. This iterator does not skip over the
>> + * &drm_gpuva_manager's @kernel_alloc_node.
>> + */
>> +#define drm_gpuva_for_each_va_range_safe(va__, next__, mgr__, start__, end__) \
>> +	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__)), \
>> +	     next__ = va ? list_next_entry(va__, rb.entry) : NULL; \
>> +	     va__ && (va__->va.addr < (end__)) && \
>> +	     !list_entry_is_head(va__, &(mgr__)->rb.list, rb.entry); \
>> +	     va__ = next__, next__ = list_next_entry(va__, rb.entry))
> 
> And this is the safe version using the drm_gpuva_next() helper:
> 
> 	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__) - (start__)), \
> 	     next__ = drm_gpuva_next(va__); \
> 	     va__ && (va__->va.addr < (end__)); \
> 	     va__ = next__, next__ = drm_gpuva_next(va__))
> 
> Those changes fixed an invalid pointer access I had in the sm_unmap()
> path.
> 

Sorry you did run into this bug.

- Danilo