linux-kernel - Re: linux-next: build failure after merge of the drm-misc tree

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:   Tue, 8 Jun 2021 09:11:57 +0200
From:   Christian König <christian.koenig@....com>
To:     Felix Kuehling <felix.kuehling@....com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Intel Graphics <intel-gfx@...ts.freedesktop.org>,
        Dave Airlie <airlied@...ux.ie>,
        DRI <dri-devel@...ts.freedesktop.org>,
        Daniel Vetter <daniel@...ll.ch>
Cc:     Alex Deucher <alexander.deucher@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the drm-misc tree

Am 08.06.21 um 09:06 schrieb Felix Kuehling:
> Am 2021-06-08 um 2:55 a.m. schrieb Christian König:
>> Hi Felix,
>>
>> that should already be fixed in drm-tip as part of the merge of the
>> TTM changes.
> No, the preempt_mgr doesn't exist in drm-misc-next. It does exist in
> drm-next, but that doesn't seem to have the TTM changes yet.
>
> Is there another DRM branch or repository that you're referring to with
> drm-tip?

drm-tip is an integration branch for conflict resolution.

E.g. when we have changes in drm-misc-next which break when we merge 
with drm-next I'm informed and need to provide a conflict resolution patch.

This is automatically applied when drm-next and drm-misc-next are merged 
together again.

It just looks like that drm-next and drm-misc-next are merged manually 
into linux-next and then the conflict resolution doesn't apply and 
everything breaks into pieces.

Adding Daniel as well. How should that be handled? Should we merge 
drm-misc-next into drm-next now?

Thanks,
Christian.

>
> Regards,
>    Fel
>
>> Regards,
>> Christian.
>>
>> Am 08.06.21 um 07:37 schrieb Felix Kuehling:
>>> Hi Christian,
>>>
>>> I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking at what
>>> changed there. Looks like I'll need to create a dummy node in
>>> amdgpu_preempt_mgr_new to satisfy TTM, and free it in
>>> amdgpu_preempt_mgr_del.
>>>
>>> Thanks,
>>>     Felix
>>>
>>>
>>> Am 2021-06-07 um 10:50 p.m. schrieb Stephen Rothwell:
>>>> Hi all,
>>>>
>>>> After merging the drm-misc tree, today's linux-next build (x86_64
>>>> allmodconfig) failed like this:
>>>>
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: In function
>>>> 'amdgpu_preempt_mgr_new':
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:75:5: error: 'struct
>>>> ttm_resource' has no member named 'mm_node'
>>>>      75 |  mem->mm_node = NULL;
>>>>         |     ^~
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: At top level:
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: error:
>>>> initialization of 'int (*)(struct ttm_resource_manager *, struct
>>>> ttm_buffer_object *, const struct ttm_place *, struct ttm_resource
>>>> **)' from incompatible pointer type 'int (*)(struct
>>>> ttm_resource_manager *, struct ttm_buffer_object *, const struct
>>>> ttm_place *, struct ttm_resource *)'
>>>> [-Werror=incompatible-pointer-types]
>>>>     129 |  .alloc = amdgpu_preempt_mgr_new,
>>>>         |           ^~~~~~~~~~~~~~~~~~~~~~
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: note: (near
>>>> initialization for 'amdgpu_preempt_mgr_func.alloc')
>>>>
>>>> Caused by commit
>>>>
>>>>     cb1c81467af3 ("drm/ttm: flip the switch for driver allocated
>>>> resources v2")
>>>>
>>>> from the drm-misc tree interacting with commit
>>>>
>>>>     b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible SG
>>>> BOs")
>>>>
>>>> from the drm tree.
>>>>
>>>> I don't know how to fix this, so I added the following hack (a better
>>>> fix would be nice):
>>>>
>>>> From: Stephen Rothwell <sfr@...b.auug.org.au>
>>>> Date: Tue, 8 Jun 2021 12:41:16 +1000
>>>> Subject: [PATCH] hack fix up for needed amdgpu_preempt_mgr_new() fix up
>>>>
>>>> Signed-off-by: Stephen Rothwell <sfr@...b.auug.org.au>
>>>> ---
>>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 4 +++-
>>>>    1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> index d607f314cc1b..e1a7b3e967b9 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>>> @@ -66,14 +66,16 @@ static DEVICE_ATTR_RO(mem_info_preempt_used);
>>>>    static int amdgpu_preempt_mgr_new(struct ttm_resource_manager *man,
>>>>                      struct ttm_buffer_object *tbo,
>>>>                      const struct ttm_place *place,
>>>> -                  struct ttm_resource *mem)
>>>> +                  struct ttm_resource **res)
>>>>    {
>>>> +#if 0
>>>>        struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
>>>>          atomic64_add(mem->num_pages, &mgr->used);
>>>>          mem->mm_node = NULL;
>>>>        mem->start = AMDGPU_BO_INVALID_OFFSET;
>>>> +#endif
>>>>        return 0;
>>>>    }
>>>>