linux-kernel - Re: drm/nouneau: 5.11 cycle regression bisected to 461619f5c324 "drm/nouveau: switch to new allocator"

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <468ec16b-d716-5bd4-db2b-fb79e6c72a4f@amd.com>
Date:   Wed, 10 Feb 2021 14:26:18 +0100
From:   Christian König <christian.koenig@....com>
To:     Mike Galbraith <efault@....de>, lkml <linux-kernel@...r.kernel.org>
Cc:     nouveau@...ts.freedesktop.org, Ben Skeggs <bskeggs@...hat.com>,
        Dave Airlie <airlied@...hat.com>
Subject: Re: drm/nouneau: 5.11 cycle regression bisected to 461619f5c324
 "drm/nouveau: switch to new allocator"



Am 10.02.21 um 13:22 schrieb Mike Galbraith:
> On Wed, 2021-02-10 at 12:44 +0100, Christian König wrote:
>> Please try to add a "return NULL" at the beginning of ttm_pool_type_take().
>>
>> That should effectively disable using the pool.
> That did away with the yield looping, but it doesn't take long for the
> display to freeze.  I ssh'd in from lappy, but there was nada in dmesg.

Yeah, that is expected. Without taking pages from the pool we leak 
memory like sieve.

At least we could narrow down the problem quite a bit with that.

Can you test the attached patch and see if it helps?

Thanks,
Christian.

>
>> Thanks for testing,
> Happy to.
>
> 	-Mike
>


View attachment "0001-drm-ttm-make-sure-pool-pages-are-cleared.patch" of type "text/x-patch" (1367 bytes)