Danilo Krummrich
2023-Jul-07 12:41 UTC
[Nouveau] [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings
On 7/7/23 13:00, Boris Brezillon wrote:> On Fri, 30 Jun 2023 00:25:18 +0200 > Danilo Krummrich <dakr at 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
Maybe Matching Threads
- [PATCH drm-next v7 02/13] drm: manager to keep track of GPUs VA mappings
- [PATCH drm-misc-next v8 01/12] drm: manager to keep track of GPUs VA mappings
- [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings
- [PATCH drm-next v2 05/16] drm: manager to keep track of GPUs VA mappings
- [PATCH drm-next v2 05/16] drm: manager to keep track of GPUs VA mappings