[AMD Official Use Only - General] Hi Christian, I have tested the proposed patch, the issue is not reproducible and everything else seems to work fine. BR, Danijel >-----Original Message----- >From: Christian König <ckoenig.leichtzumerken@xxxxxxxxx> >Sent: Thursday, January 26, 2023 1:20 PM >To: Slivka, Danijel <Danijel.Slivka@xxxxxxx>; Thomas Zimmermann ><tzimmermann@xxxxxxx> >Cc: Deucher, Alexander <Alexander.Deucher@xxxxxxx>; dri-devel <dri- >devel@xxxxxxxxxxxxxxxxxxxxx>; Sharma, Shashank <Shashank.Sharma@xxxxxxx> >Subject: Re: Amdgpu module is references even after unbinding the vtcon > >Am 26.01.23 um 10:49 schrieb Slivka, Danijel: >> [AMD Official Use Only - General] >> >> Hi Thomas, >> >> I have checked what you mentioned. >> When loading amdgpu we call drm_client_init() during fbdev setup [1], the >refcnt for drm_kms_helper increases from 3 -> 4. >> When we unbind vtcon, refcnt for drm_kms_helper drops 4 -> 3, but the >drm_client_release() [2] is not called. >> The drm_client_release() is called only when unloading the amdgpu driver. >> >> Is this expected? > >Yes, the client can't be released because it is possible that the vtcon is bound to >this fbdev again. > >Please test the handle work around I've send around internally. At least for me >that approach seems to work. > >Regards, >Christian. > >> >> There is a comment for drm_client_release with regards to fbdev : >> * This function should only be called from the unregister callback. An exception >> * is fbdev which cannot free the buffer if userspace has open file descriptors. >> >> Could this be relevant for our use case, although as Application/X/GDM are >stopped at that point and no fd should be open. >> >> Thank you, >> BR, >> Danijel >> >>> -----Original Message----- >>> From: Thomas Zimmermann <tzimmermann@xxxxxxx> >>> Sent: Wednesday, January 25, 2023 8:48 PM >>> To: Christian König <ckoenig.leichtzumerken@xxxxxxxxx> >>> Cc: Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Slivka, Danijel >>> <Danijel.Slivka@xxxxxxx>; dri-devel >>> <dri-devel@xxxxxxxxxxxxxxxxxxxxx>; Sharma, Shashank >>> <Shashank.Sharma@xxxxxxx> >>> Subject: Re: Amdgpu module is references even after unbinding the >>> vtcon >>> >>> Hi Christian >>> >>> Am 24.01.23 um 15:12 schrieb Christian König: >>>> Hi Thomas, >>>> >>>> we ran into a problem with the general fbcon/fbdev implementation >>>> and though that you might have some idea. >>>> >>>> What happens is the following: >>>> 1. We load amdgpu and get our normal fbcon. >>>> 2. fbcon allocates a dump BO as backing store for the console. >>>> 3. GDM/X/Applications start, new framebuffers are created BOs >>>> imported, exported etc... >>>> 4. Somehow X or GDM iterated over all the framebuffer objects the >>>> kernels knows about and export them as DMA-buf. >>>> 5. Application/X/GDM are stopped, handles closed, framebuffers >>>> released etc... >>>> 6. We unbind vtcon. >>>> >>>> At this point the amdgpu module usually has a reference count of 0 >>>> and can be unloaded, but since GDM/X/Whoever iterated over all the >>>> known framebuffers and exported them as DMA-buf (for whatever reason >>>> idk) we now still have an exported DMA-buf and with it a reference to the >module. >>>> >>>> Any idea how we could prevent that? >>> Here's another stab in the dark. >>> >>> The big difference between old-style fbdev and the new one is that >>> the old fbdev setup (e.g., radeon) allocates a GEM object and puts >>> together the fbdev data structures from the BO in a fairly hackish >>> way. The new style uses an in-kernel client with a file to allocate >>> the BO via dumb buffers; and holds a reference to the DRM module. >>> >>> Maybe the reference comes from the in-kernel DRM client itself. [1] >>> Check if the client resources get released [2] when you unbind vtcon. >>> >>> Best regards >>> Thomas >>> >>> [1] >>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_cl >>> ient.c#L87 >>> [2] >>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_cl >>> ient.c#L16 >>> 0 >>> >>>> Thanks, >>>> Christian. >>> -- >>> Thomas Zimmermann >>> Graphics Driver Developer >>> SUSE Software Solutions Germany GmbH >>> Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) >>> Geschäftsführer: Ivo Totev
