Re: Amdgpu module is references even after unbinding the vtcon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

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?

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.

This looks like the bug to me.

I'm not sure why the client code takes the module reference in the first place. Drivers invoke client interface directly. Shouldn't that imply that they have a module reference already?

Best regards
Thomas


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_client.c#L87
[2]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_client.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

--
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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux