[PATCH] drm/ttm: fix use-after-free races in vm fault handling

Daniel Vetter daniel at ffwll.ch
Mon Feb 27 09:08:47 UTC 2017


On Mon, Feb 27, 2017 at 09:56:56AM +0100, Christian König wrote:
> Am 26.02.2017 um 22:35 schrieb Daniel Vetter:
> > On Sun, Feb 19, 2017 at 10:32:43AM +0100, Christian König wrote:
> > > Am 18.02.2017 um 23:50 schrieb Nicolai Hähnle:
> > > > From: Nicolai Hähnle <nicolai.haehnle at amd.com>
> > > > 
> > > > The vm fault handler relies on the fact that the VMA owns a reference
> > > > to the BO. However, once mmap_sem is released, other tasks are free to
> > > > destroy the VMA, which can lead to the BO being freed. Fix two code
> > > > paths where that can happen, both related to vm fault retries.
> > > > 
> > > > Found via a lock debugging warning which flagged &bo->wu_mutex as
> > > > locked while being destroyed.
> > > > 
> > > > Fixes: cbe12e74ee4e ("drm/ttm: Allow vm fault retries")
> > > > Signed-off-by: Nicolai Hähnle <nicolai.haehnle at amd.com>
> > > Good catch! Patch is Reviewed-by: Christian König <christian.koenig at amd.com>
> > Since you have commit rights and all, care to push to drm-misc.git?
> 
> Do I have to use dim or could I just push the patches using standard git?
> 
> See my problem with installing an extra tool in my dev environment is that I
> have 5+ hard disks setup from an image with all the neat stuff I need.
> Distributing something new in there would be rather painful for me.
> 
> On the other hand I could just setup my laptop and use that one as a bridge
> for pushing into drm-misc. That would work for single bug fixes like this,
> but would break my usual development workflow.

Atm the big magic in dim is in the integration tree construction and
faning out conflict handling to everyone. There's also the upshot of being
able to share sanity checks for silly fumbles, but we don't yet have much
of these, so dim's indeed needed. I know it's annoying.

I can apply this one here if you don't want to fiddle with it all for now.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the amd-gfx mailing list