On Mon, Feb 27, 2017 at 10:08:47AM +0100, Daniel Vetter wrote:
> 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
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
> > > >
> > > > The vm fault hand
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
The vm fault handler relies on the fact that the VMA owns a reference
to the BO. However, once mmap_sem is release
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
> >
> > 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
> > d
Am 18.02.2017 um 23:50 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
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 c
From: Nicolai Hähnle
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.
Fou
