linux-kernel - Re: nouveau: failed to initialise sync

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]

Date:   Wed, 14 Jul 2021 15:02:21 +0200
From:   Christian König <christian.koenig@....com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>, airlied@...ux.ie,
        daniel@...ll.ch
Cc:     Alistair Popple <apopple@...dia.com>,
        Corentin Labbe <clabbe.montjoie@...il.com>, bskeggs@...hat.com,
        dri-devel@...ts.freedesktop.org, nouveau@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Subject: Re: nouveau: failed to initialise sync

Am 14.07.21 um 14:56 schrieb Kirill A. Shutemov:
> On Tue, Jul 06, 2021 at 08:58:37AM +0200, Christian König wrote:
>> Hi guys,
>>
>> yes nouveau was using the same functionality for internal BOs without
>> noticing it. This is fixes by the following commit:
>>
>> commit d098775ed44021293b1962dea61efb19297b8d02
>> Author: Christian König <christian.koenig@....com>
>> Date:   Wed Jun 9 19:25:56 2021 +0200
>>
>>      drm/nouveau: init the base GEM fields for internal BOs
>>
>>      TTMs buffer objects are based on GEM objects for quite a while
>>      and rely on initializing those fields before initializing the TTM BO.
>>
>>      Nouveau now doesn't init the GEM object for internally allocated BOs,
>>      so make sure that we at least initialize some necessary fields.
>>
>> Could be that the patch needs to be send to stable as well.
> The regression is present in v5.14-rc1. Any idea when it will hit
> upstream? I don't see it being applied to drm=next.

Well that question needs to answer Dave or somebody else from the 
drm-misc maintainer team.

This fix together with some others are already in drm-misc-next-fixes 
waiting to be pushed upstream, but it looks like that hasn't happened yet.

Even Linus already pinged me where the fix for qxl got stuck.

Regards,
Christian.