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
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
> > > >
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.
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,
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
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