linux-kernel - Re: [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZKkEkoHSGwICKwHf@DUT025-TGLU.fm.intel.com>
Date:   Sat, 8 Jul 2023 06:39:14 +0000
From:   Matthew Brost <matthew.brost@...el.com>
To:     Boris Brezillon <boris.brezillon@...labora.com>
CC:     Danilo Krummrich <dakr@...hat.com>, <airlied@...il.com>,
        <daniel@...ll.ch>, <tzimmermann@...e.de>, <mripard@...nel.org>,
        <corbet@....net>, <christian.koenig@....com>, <bskeggs@...hat.com>,
        <Liam.Howlett@...cle.com>, <alexdeucher@...il.com>,
        <ogabbay@...nel.org>, <bagasdotme@...il.com>,
        <willy@...radead.org>, <jason@...kstrand.net>,
        <dri-devel@...ts.freedesktop.org>, <nouveau@...ts.freedesktop.org>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Donald Robson <donald.robson@...tec.com>,
        Dave Airlie <airlied@...hat.com>
Subject: Re: [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA
 mappings

On Fri, Jul 07, 2023 at 02:52:41PM +0200, Boris Brezillon wrote:
> On Fri, 7 Jul 2023 14:41:23 +0200
> Danilo Krummrich <dakr@...hat.com> wrote:
> 
> > >> +	     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.
> 
> If you want to keep drm_gpuva_find_next(), feel free to rename/prefix
> the drm_gpuva_next() function. I was just posting it as a reference.
> 
> > 
> > > 
> > > 	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.
> 
> No worries, that's what testing/debugging/reviewing is for. And I'm glad
> someone decided to work on this gpuva stuff so I don't have to code it
> myself, so that's the least I can do.

With Boris's changes this version works in Xe.

With that:

Acked-by: Matthew Brost <matthew.brost@...el.com>
Tested-by: Matthew Brost <matthew.brost@...el.com>