On Tue, 23 Sep 2014, Daniel Vetter wrote:
> On Mon, Sep 22, 2014 at 08:25:21AM -0700, bradley.d.vol...@intel.com wrote:
>> From: Brad Volkin
>>
>> Ring init and cleanup are not balanced because we re-init the rings on
>> resume without having cleaned them up on suspend. This leads to the
>> driv
On Tue, Sep 23, 2014 at 10:14:33AM +0100, Chris Wilson wrote:
> On Tue, Sep 23, 2014 at 10:34:46AM +0200, Daniel Vetter wrote:
> > On Mon, Sep 22, 2014 at 08:25:21AM -0700, bradley.d.vol...@intel.com wrote:
> > > From: Brad Volkin
> > >
> > > Ring init and cleanup are not balanced because we re-i
On Tue, Sep 23, 2014 at 10:34:46AM +0200, Daniel Vetter wrote:
> On Mon, Sep 22, 2014 at 08:25:21AM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > Ring init and cleanup are not balanced because we re-init the rings on
> > resume without having cleaned them up on suspend. T
On Mon, Sep 22, 2014 at 08:25:21AM -0700, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> Ring init and cleanup are not balanced because we re-init the rings on
> resume without having cleaned them up on suspend. This leads to the
> driver leaking the parser's hash tables with a kmemlea
From: Brad Volkin
Ring init and cleanup are not balanced because we re-init the rings on
resume without having cleaned them up on suspend. This leads to the
driver leaking the parser's hash tables with a kmemleak signature such
as this:
unreferenced object 0x880405960980 (size 32):
comm "s