All of lore.kernel.org
 help / color / mirror / Atom feed
* vmwgfx leaking bo pins?
@ 2021-03-11 10:46 Thomas Hellström (Intel)
  2021-03-11 11:32 ` AW: " Koenig, Christian
  2021-03-11 21:07 ` Zack Rusin
  0 siblings, 2 replies; 12+ messages in thread
From: Thomas Hellström (Intel) @ 2021-03-11 10:46 UTC (permalink / raw)
  To: Daniel Vetter, Christian König, linux-graphics-maintainer
  Cc: DRI Development

Hi,

I tried latest drm-fixes today and saw a lot of these: Fallout from ttm 
rework?

/Thomas

[  298.404788] WARNING: CPU: 1 PID: 3839 at 
drivers/gpu/drm/ttm/ttm_bo.c:512 ttm_bo_release+0x2b5/0x300 [ttm]
[  298.404795] Modules linked in: nls_utf8 isofs rfcomm tun bridge stp 
llc ip6table_nat ip6table_mangle ip6table_raw ip6table_security 
iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 
iptable_mangle iptable_raw iptable_security ip_set nfnetlink 
ip6table_filter ip6_tables iptable_filter cmac bnep vsock_loopback 
vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock 
snd_seq_midi snd_seq_midi_event intel_rapl_msr snd_ens1371 
snd_ac97_codec ac97_bus vmw_balloon intel_rapl_common snd_seq rapl 
snd_pcm btusb btrtl btbcm btintel bluetooth joydev gameport snd_timer 
snd_rawmidi snd_seq_device rfkill snd ecdh_generic vmw_vmci ecc 
soundcore i2c_piix4 auth_rpcgss sunrpc ip_tables vmwgfx drm_kms_helper 
cec ttm e1000 crct10dif_pclmul crc32_pclmul crc32c_intel 
ghash_clmulni_intel drm mptspi serio_raw scsi_transport_spi mptscsih 
mptbase ata_generic pata_acpi uas usb_storage fuse
[  298.404837] CPU: 1 PID: 3839 Comm: thunderbird Tainted: G        
W         5.12.0-rc2+ #42
[  298.404839] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 07/29/2019
[  298.404840] RIP: 0010:ttm_bo_release+0x2b5/0x300 [ttm]
[  298.404845] Code: e8 a0 f3 35 ce e9 da fd ff ff 49 8b 7e 90 b9 30 75 
00 00 31 d2 be 01 00 00 00 e8 c6 17 36 ce 49 8b 46 e0 eb 9e 48 89 e8 eb 
99 <0f> 0b 41 c7 86 94 00 00 00 00 00 00 00 49 8d 76 08 31 d2 4c 89 ef
[  298.404847] RSP: 0018:ffffb24a43ef3bd0 EFLAGS: 00010202
[  298.404848] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 
0000000000000001
[  298.404850] RDX: 0000000000000001 RSI: 0000000000000246 RDI: 
ffffffffc03c50e8
[  298.404851] RBP: ffff9ad4429f2620 R08: 0000000000000001 R09: 
ffff9ad4429f2000
[  298.404852] R10: ffff9ad48664e090 R11: 0000000000000000 R12: 
ffff9ad4e71371d0
[  298.404852] R13: ffff9ad4e7137000 R14: ffff9ad4e7137168 R15: 
ffff9ad48710f4c0
[  298.404854] FS:  00007fc6d9ae4780(0000) GS:ffff9ad576e40000(0000) 
knlGS:0000000000000000
[  298.404855] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  298.404857] CR2: 00007fc6c6740000 CR3: 00000001a4eac004 CR4: 
00000000003706e0
[  298.404864] Call Trace:
[  298.404866]  vmw_resource_release+0x131/0x1f0 [vmwgfx]
[  298.404878]  vmw_context_cotables_unref.isra.0+0x6f/0xa0 [vmwgfx]
[  298.404891]  vmw_resource_release+0x16a/0x1f0 [vmwgfx]
[  298.404901]  vmw_user_context_base_release+0x31/0x50 [vmwgfx]
[  298.404912]  ttm_release_base+0x7f/0xc0 [vmwgfx]
[  298.404922]  ttm_ref_object_release+0xde/0xf0 [vmwgfx]
[  298.404931]  ttm_ref_object_base_unref+0x8e/0xb0 [vmwgfx]
[  298.404940]  ? vmw_dx_context_unbind+0x1e0/0x1e0 [vmwgfx]
[  298.404951]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[  298.404974]  drm_ioctl+0x20f/0x3a0 [drm]
[  298.404991]  ? vmw_dx_context_unbind+0x1e0/0x1e0 [vmwgfx]
[  298.405003]  ? selinux_file_ioctl+0x135/0x230
[  298.405006]  ? drm_version+0x90/0x90 [drm]
[  298.405023]  vmw_generic_ioctl+0xab/0x150 [vmwgfx]
[  298.405033]  __x64_sys_ioctl+0x83/0xb0
[  298.405035]  do_syscall_64+0x33/0x40
[  298.405038]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  298.405041] RIP: 0033:0x7fc6d9be15db
[  298.405042] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff 
ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6d b8 0c 00 f7 d8 64 89 01 48
[  298.405044] RSP: 002b:00007ffc8ce6de98 EFLAGS: 00000246 ORIG_RAX: 
0000000000000010
[  298.405046] RAX: ffffffffffffffda RBX: 00007ffc8ce6dee0 RCX: 
00007fc6d9be15db
[  298.405048] RDX: 00007ffc8ce6dee0 RSI: 0000000040086448 RDI: 
0000000000000007
[  298.405049] RBP: 0000000040086448 R08: 0000000000000000 R09: 
0000000000000000
[  298.405050] R10: 0000000000000000 R11: 0000000000000246 R12: 
00007fc6d98e0000
[  298.405051] R13: 0000000000000007 R14: 00007fc6d98ea3b0 R15: 
00007fc6c671f800
[  298.405053] ---[ end trace c628fb3ea8b5aa96 ]---

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* AW: vmwgfx leaking bo pins?
  2021-03-11 10:46 vmwgfx leaking bo pins? Thomas Hellström (Intel)
@ 2021-03-11 11:32 ` Koenig, Christian
  2021-03-11 12:36   ` Thomas Hellström (Intel)
  2021-03-11 21:07 ` Zack Rusin
  1 sibling, 1 reply; 12+ messages in thread
From: Koenig, Christian @ 2021-03-11 11:32 UTC (permalink / raw)
  To: Thomas Hellström (Intel), Daniel Vetter, linux-graphics-maintainer
  Cc: DRI Development


[-- Attachment #1.1: Type: text/plain, Size: 4721 bytes --]

We are investigating a similar problem with radeon.

So far no idea what's going wrong since it doesn't seem to happen with amdgpu.

If you have an idea please speak up :)

Thanks,
Christian.
________________________________
Von: Thomas Hellström (Intel) <thomas_os@shipmail.org>
Gesendet: Donnerstag, 11. März 2021 11:46
An: Daniel Vetter <daniel.vetter@ffwll.ch>; Koenig, Christian <Christian.Koenig@amd.com>; linux-graphics-maintainer@vmware.com <linux-graphics-maintainer@vmware.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Betreff: vmwgfx leaking bo pins?

Hi,

I tried latest drm-fixes today and saw a lot of these: Fallout from ttm
rework?

/Thomas

[  298.404788] WARNING: CPU: 1 PID: 3839 at
drivers/gpu/drm/ttm/ttm_bo.c:512 ttm_bo_release+0x2b5/0x300 [ttm]
[  298.404795] Modules linked in: nls_utf8 isofs rfcomm tun bridge stp
llc ip6table_nat ip6table_mangle ip6table_raw ip6table_security
iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4
iptable_mangle iptable_raw iptable_security ip_set nfnetlink
ip6table_filter ip6_tables iptable_filter cmac bnep vsock_loopback
vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock
snd_seq_midi snd_seq_midi_event intel_rapl_msr snd_ens1371
snd_ac97_codec ac97_bus vmw_balloon intel_rapl_common snd_seq rapl
snd_pcm btusb btrtl btbcm btintel bluetooth joydev gameport snd_timer
snd_rawmidi snd_seq_device rfkill snd ecdh_generic vmw_vmci ecc
soundcore i2c_piix4 auth_rpcgss sunrpc ip_tables vmwgfx drm_kms_helper
cec ttm e1000 crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel drm mptspi serio_raw scsi_transport_spi mptscsih
mptbase ata_generic pata_acpi uas usb_storage fuse
[  298.404837] CPU: 1 PID: 3839 Comm: thunderbird Tainted: G
W         5.12.0-rc2+ #42
[  298.404839] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 07/29/2019
[  298.404840] RIP: 0010:ttm_bo_release+0x2b5/0x300 [ttm]
[  298.404845] Code: e8 a0 f3 35 ce e9 da fd ff ff 49 8b 7e 90 b9 30 75
00 00 31 d2 be 01 00 00 00 e8 c6 17 36 ce 49 8b 46 e0 eb 9e 48 89 e8 eb
99 <0f> 0b 41 c7 86 94 00 00 00 00 00 00 00 49 8d 76 08 31 d2 4c 89 ef
[  298.404847] RSP: 0018:ffffb24a43ef3bd0 EFLAGS: 00010202
[  298.404848] RAX: 0000000000000001 RBX: 0000000000000000 RCX:
0000000000000001
[  298.404850] RDX: 0000000000000001 RSI: 0000000000000246 RDI:
ffffffffc03c50e8
[  298.404851] RBP: ffff9ad4429f2620 R08: 0000000000000001 R09:
ffff9ad4429f2000
[  298.404852] R10: ffff9ad48664e090 R11: 0000000000000000 R12:
ffff9ad4e71371d0
[  298.404852] R13: ffff9ad4e7137000 R14: ffff9ad4e7137168 R15:
ffff9ad48710f4c0
[  298.404854] FS:  00007fc6d9ae4780(0000) GS:ffff9ad576e40000(0000)
knlGS:0000000000000000
[  298.404855] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  298.404857] CR2: 00007fc6c6740000 CR3: 00000001a4eac004 CR4:
00000000003706e0
[  298.404864] Call Trace:
[  298.404866]  vmw_resource_release+0x131/0x1f0 [vmwgfx]
[  298.404878]  vmw_context_cotables_unref.isra.0+0x6f/0xa0 [vmwgfx]
[  298.404891]  vmw_resource_release+0x16a/0x1f0 [vmwgfx]
[  298.404901]  vmw_user_context_base_release+0x31/0x50 [vmwgfx]
[  298.404912]  ttm_release_base+0x7f/0xc0 [vmwgfx]
[  298.404922]  ttm_ref_object_release+0xde/0xf0 [vmwgfx]
[  298.404931]  ttm_ref_object_base_unref+0x8e/0xb0 [vmwgfx]
[  298.404940]  ? vmw_dx_context_unbind+0x1e0/0x1e0 [vmwgfx]
[  298.404951]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[  298.404974]  drm_ioctl+0x20f/0x3a0 [drm]
[  298.404991]  ? vmw_dx_context_unbind+0x1e0/0x1e0 [vmwgfx]
[  298.405003]  ? selinux_file_ioctl+0x135/0x230
[  298.405006]  ? drm_version+0x90/0x90 [drm]
[  298.405023]  vmw_generic_ioctl+0xab/0x150 [vmwgfx]
[  298.405033]  __x64_sys_ioctl+0x83/0xb0
[  298.405035]  do_syscall_64+0x33/0x40
[  298.405038]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  298.405041] RIP: 0033:0x7fc6d9be15db
[  298.405042] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff
ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6d b8 0c 00 f7 d8 64 89 01 48
[  298.405044] RSP: 002b:00007ffc8ce6de98 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[  298.405046] RAX: ffffffffffffffda RBX: 00007ffc8ce6dee0 RCX:
00007fc6d9be15db
[  298.405048] RDX: 00007ffc8ce6dee0 RSI: 0000000040086448 RDI:
0000000000000007
[  298.405049] RBP: 0000000040086448 R08: 0000000000000000 R09:
0000000000000000
[  298.405050] R10: 0000000000000000 R11: 0000000000000246 R12:
00007fc6d98e0000
[  298.405051] R13: 0000000000000007 R14: 00007fc6d98ea3b0 R15:
00007fc6c671f800
[  298.405053] ---[ end trace c628fb3ea8b5aa96 ]---


[-- Attachment #1.2: Type: text/html, Size: 7271 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: AW: vmwgfx leaking bo pins?
  2021-03-11 11:32 ` AW: " Koenig, Christian
@ 2021-03-11 12:36   ` Thomas Hellström (Intel)
  0 siblings, 0 replies; 12+ messages in thread
From: Thomas Hellström (Intel) @ 2021-03-11 12:36 UTC (permalink / raw)
  To: Koenig, Christian, Daniel Vetter, linux-graphics-maintainer
  Cc: DRI Development


[-- Attachment #1.1: Type: text/plain, Size: 5046 bytes --]


On 3/11/21 12:32 PM, Koenig, Christian wrote:
> We are investigating a similar problem with radeon.
>
> So far no idea what's going wrong since it doesn't seem to happen with 
> amdgpu.
>
> If you have an idea please speak up :)

Sure. No idea ATM. Was just fiddling a bit with vmwgfx to experiment 
with the fix for the huge page-table-entry issue.

/Thomas


>
> Thanks,
> Christian.
> ------------------------------------------------------------------------
> *Von:* Thomas Hellström (Intel) <thomas_os@shipmail.org>
> *Gesendet:* Donnerstag, 11. März 2021 11:46
> *An:* Daniel Vetter <daniel.vetter@ffwll.ch>; Koenig, Christian 
> <Christian.Koenig@amd.com>; linux-graphics-maintainer@vmware.com 
> <linux-graphics-maintainer@vmware.com>
> *Cc:* DRI Development <dri-devel@lists.freedesktop.org>
> *Betreff:* vmwgfx leaking bo pins?
> Hi,
>
> I tried latest drm-fixes today and saw a lot of these: Fallout from ttm
> rework?
>
> /Thomas
>
> [  298.404788] WARNING: CPU: 1 PID: 3839 at
> drivers/gpu/drm/ttm/ttm_bo.c:512 ttm_bo_release+0x2b5/0x300 [ttm]
> [  298.404795] Modules linked in: nls_utf8 isofs rfcomm tun bridge stp
> llc ip6table_nat ip6table_mangle ip6table_raw ip6table_security
> iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4
> iptable_mangle iptable_raw iptable_security ip_set nfnetlink
> ip6table_filter ip6_tables iptable_filter cmac bnep vsock_loopback
> vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock
> snd_seq_midi snd_seq_midi_event intel_rapl_msr snd_ens1371
> snd_ac97_codec ac97_bus vmw_balloon intel_rapl_common snd_seq rapl
> snd_pcm btusb btrtl btbcm btintel bluetooth joydev gameport snd_timer
> snd_rawmidi snd_seq_device rfkill snd ecdh_generic vmw_vmci ecc
> soundcore i2c_piix4 auth_rpcgss sunrpc ip_tables vmwgfx drm_kms_helper
> cec ttm e1000 crct10dif_pclmul crc32_pclmul crc32c_intel
> ghash_clmulni_intel drm mptspi serio_raw scsi_transport_spi mptscsih
> mptbase ata_generic pata_acpi uas usb_storage fuse
> [  298.404837] CPU: 1 PID: 3839 Comm: thunderbird Tainted: G
> W         5.12.0-rc2+ #42
> [  298.404839] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
> Desktop Reference Platform, BIOS 6.00 07/29/2019
> [  298.404840] RIP: 0010:ttm_bo_release+0x2b5/0x300 [ttm]
> [  298.404845] Code: e8 a0 f3 35 ce e9 da fd ff ff 49 8b 7e 90 b9 30 75
> 00 00 31 d2 be 01 00 00 00 e8 c6 17 36 ce 49 8b 46 e0 eb 9e 48 89 e8 eb
> 99 <0f> 0b 41 c7 86 94 00 00 00 00 00 00 00 49 8d 76 08 31 d2 4c 89 ef
> [  298.404847] RSP: 0018:ffffb24a43ef3bd0 EFLAGS: 00010202
> [  298.404848] RAX: 0000000000000001 RBX: 0000000000000000 RCX:
> 0000000000000001
> [  298.404850] RDX: 0000000000000001 RSI: 0000000000000246 RDI:
> ffffffffc03c50e8
> [  298.404851] RBP: ffff9ad4429f2620 R08: 0000000000000001 R09:
> ffff9ad4429f2000
> [  298.404852] R10: ffff9ad48664e090 R11: 0000000000000000 R12:
> ffff9ad4e71371d0
> [  298.404852] R13: ffff9ad4e7137000 R14: ffff9ad4e7137168 R15:
> ffff9ad48710f4c0
> [  298.404854] FS:  00007fc6d9ae4780(0000) GS:ffff9ad576e40000(0000)
> knlGS:0000000000000000
> [  298.404855] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  298.404857] CR2: 00007fc6c6740000 CR3: 00000001a4eac004 CR4:
> 00000000003706e0
> [  298.404864] Call Trace:
> [  298.404866]  vmw_resource_release+0x131/0x1f0 [vmwgfx]
> [  298.404878] vmw_context_cotables_unref.isra.0+0x6f/0xa0 [vmwgfx]
> [  298.404891]  vmw_resource_release+0x16a/0x1f0 [vmwgfx]
> [  298.404901]  vmw_user_context_base_release+0x31/0x50 [vmwgfx]
> [  298.404912]  ttm_release_base+0x7f/0xc0 [vmwgfx]
> [  298.404922]  ttm_ref_object_release+0xde/0xf0 [vmwgfx]
> [  298.404931]  ttm_ref_object_base_unref+0x8e/0xb0 [vmwgfx]
> [  298.404940]  ? vmw_dx_context_unbind+0x1e0/0x1e0 [vmwgfx]
> [  298.404951]  drm_ioctl_kernel+0xaa/0xf0 [drm]
> [  298.404974]  drm_ioctl+0x20f/0x3a0 [drm]
> [  298.404991]  ? vmw_dx_context_unbind+0x1e0/0x1e0 [vmwgfx]
> [  298.405003]  ? selinux_file_ioctl+0x135/0x230
> [  298.405006]  ? drm_version+0x90/0x90 [drm]
> [  298.405023]  vmw_generic_ioctl+0xab/0x150 [vmwgfx]
> [  298.405033]  __x64_sys_ioctl+0x83/0xb0
> [  298.405035]  do_syscall_64+0x33/0x40
> [  298.405038]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [  298.405041] RIP: 0033:0x7fc6d9be15db
> [  298.405042] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff
> ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f
> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6d b8 0c 00 f7 d8 64 89 01 48
> [  298.405044] RSP: 002b:00007ffc8ce6de98 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000010
> [  298.405046] RAX: ffffffffffffffda RBX: 00007ffc8ce6dee0 RCX:
> 00007fc6d9be15db
> [  298.405048] RDX: 00007ffc8ce6dee0 RSI: 0000000040086448 RDI:
> 0000000000000007
> [  298.405049] RBP: 0000000040086448 R08: 0000000000000000 R09:
> 0000000000000000
> [  298.405050] R10: 0000000000000000 R11: 0000000000000246 R12:
> 00007fc6d98e0000
> [  298.405051] R13: 0000000000000007 R14: 00007fc6d98ea3b0 R15:
> 00007fc6c671f800
> [  298.405053] ---[ end trace c628fb3ea8b5aa96 ]---
>

[-- Attachment #1.2: Type: text/html, Size: 10107 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-11 10:46 vmwgfx leaking bo pins? Thomas Hellström (Intel)
  2021-03-11 11:32 ` AW: " Koenig, Christian
@ 2021-03-11 21:07 ` Zack Rusin
  2021-03-11 22:35   ` Thomas Hellström (Intel)
  1 sibling, 1 reply; 12+ messages in thread
From: Zack Rusin @ 2021-03-11 21:07 UTC (permalink / raw)
  To: Thomas Hellström (Intel)
  Cc: Daniel Vetter, Linux-graphics-maintainer, Christian König,
	DRI Development


> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) <thomas_os@shipmail.org> wrote:
> 
> Hi,
> 
> I tried latest drm-fixes today and saw a lot of these: Fallout from ttm rework?

Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was in drm-misc-next in the drm-misc tree for a while but hasn’t been merged for 5.12.

z

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-11 21:07 ` Zack Rusin
@ 2021-03-11 22:35   ` Thomas Hellström (Intel)
  2021-03-11 23:02     ` Zack Rusin
  0 siblings, 1 reply; 12+ messages in thread
From: Thomas Hellström (Intel) @ 2021-03-11 22:35 UTC (permalink / raw)
  To: Zack Rusin
  Cc: Daniel Vetter, Linux-graphics-maintainer, Christian König,
	DRI Development

Hi, Zack

On 3/11/21 10:07 PM, Zack Rusin wrote:
>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) <thomas_os@shipmail.org> wrote:
>>
>> Hi,
>>
>> I tried latest drm-fixes today and saw a lot of these: Fallout from ttm rework?
> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was in drm-misc-next in the drm-misc tree for a while but hasn’t been merged for 5.12.
>
> z
>
Hmm, yes but doesn't that fix trip the ttm_bo_unpin() 
dma_resv_assert_held(bo->base.resv)?

Taking the reservation to unpin at TTM bo free has always been awkward 
and that's why vmwgfx and I guess other TTM drivers have been sloppy 
doing that as TTM never cared. Perhaps TTM could change the pin_count to 
an atomic and allow unlocked unpinning? still requiring the reservation 
lock for pin_count transition 0->1, though.

Also, pinning at bo creation in vmwgfx has been to do the equivalent of 
ttm_bo_init_reserved() (which api was added later). Creating pinned 
would make the object isolated and allowing the reserve trylock that 
followed to always succeed. With the introduction of the TTM pin_count, 
it seems ttm_bo_init_reserved() is used to enable pinned creation which 
is used to emulate ttm_bo_init_reserved() :)

/Thomas



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-11 22:35   ` Thomas Hellström (Intel)
@ 2021-03-11 23:02     ` Zack Rusin
  2021-03-12  8:13       ` Christian König
  2021-03-12 10:06       ` Thomas Hellström (Intel)
  0 siblings, 2 replies; 12+ messages in thread
From: Zack Rusin @ 2021-03-11 23:02 UTC (permalink / raw)
  To: Thomas Hellström (Intel)
  Cc: Daniel Vetter, Linux-graphics-maintainer, Christian König,
	DRI Development



> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel) <thomas_os@shipmail.org> wrote:
> 
> Hi, Zack
> 
> On 3/11/21 10:07 PM, Zack Rusin wrote:
>>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) <thomas_os@shipmail.org> wrote:
>>> 
>>> Hi,
>>> 
>>> I tried latest drm-fixes today and saw a lot of these: Fallout from ttm rework?
>> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was in drm-misc-next in the drm-misc tree for a while but hasn’t been merged for 5.12.
>> 
>> z
>> 
> Hmm, yes but doesn't that fix trip the ttm_bo_unpin() dma_resv_assert_held(bo->base.resv)?

No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be working fine.

> Taking the reservation to unpin at TTM bo free has always been awkward and that's why vmwgfx and I guess other TTM drivers have been sloppy doing that as TTM never cared. Perhaps TTM could change the pin_count to an atomic and allow unlocked unpinning? still requiring the reservation lock for pin_count transition 0->1, though.

Yea, that’d probably make sense. I think in general just making sure the requirements are consistent and well documented would be great.

> Also, pinning at bo creation in vmwgfx has been to do the equivalent of ttm_bo_init_reserved() (which api was added later). Creating pinned would make the object isolated and allowing the reserve trylock that followed to always succeed. With the introduction of the TTM pin_count, it seems ttm_bo_init_reserved() is used to enable pinned creation which is used to emulate ttm_bo_init_reserved() :)

Yea, we should probably port the vmwgfx code to ttm_bo_init_reserved just to be match the newly established semantics.
z
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-11 23:02     ` Zack Rusin
@ 2021-03-12  8:13       ` Christian König
  2021-03-12 10:06       ` Thomas Hellström (Intel)
  1 sibling, 0 replies; 12+ messages in thread
From: Christian König @ 2021-03-12  8:13 UTC (permalink / raw)
  To: Zack Rusin, Thomas Hellström (Intel)
  Cc: Daniel Vetter, Linux-graphics-maintainer, DRI Development



Am 12.03.21 um 00:02 schrieb Zack Rusin:
>
>> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel) <thomas_os@shipmail.org> wrote:
>>
>> Hi, Zack
>>
>> On 3/11/21 10:07 PM, Zack Rusin wrote:
>>>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) <thomas_os@shipmail.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I tried latest drm-fixes today and saw a lot of these: Fallout from ttm rework?
>>> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was in drm-misc-next in the drm-misc tree for a while but hasn’t been merged for 5.12.

Mhm, crap. I hoped that you would have the same issue as radeon somehow 
and could help with debugging.

Please make sure the patch is pushed to drm-misc-fixes so that it ends 
up fixed in 5.12.

>>>
>>> z
>>>
>> Hmm, yes but doesn't that fix trip the ttm_bo_unpin() dma_resv_assert_held(bo->base.resv)?
> No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be working fine.
>
>> Taking the reservation to unpin at TTM bo free has always been awkward and that's why vmwgfx and I guess other TTM drivers have been sloppy doing that as TTM never cared. Perhaps TTM could change the pin_count to an atomic and allow unlocked unpinning? still requiring the reservation lock for pin_count transition 0->1, though.
> Yea, that’d probably make sense. I think in general just making sure the requirements are consistent and well documented would be great.
>
>> Also, pinning at bo creation in vmwgfx has been to do the equivalent of ttm_bo_init_reserved() (which api was added later). Creating pinned would make the object isolated and allowing the reserve trylock that followed to always succeed. With the introduction of the TTM pin_count, it seems ttm_bo_init_reserved() is used to enable pinned creation which is used to emulate ttm_bo_init_reserved() :)
> Yea, we should probably port the vmwgfx code to ttm_bo_init_reserved just to be match the newly established semantics.

Yeah, I stumbled over that at well during one of the cleanups and 
considered changing the implementation. But then it got lost in all the 
rework.

Christian.

> z

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-11 23:02     ` Zack Rusin
  2021-03-12  8:13       ` Christian König
@ 2021-03-12 10:06       ` Thomas Hellström (Intel)
  2021-03-15 17:57         ` Zack Rusin
  1 sibling, 1 reply; 12+ messages in thread
From: Thomas Hellström (Intel) @ 2021-03-12 10:06 UTC (permalink / raw)
  To: dri-devel


On 3/12/21 12:02 AM, Zack Rusin wrote:
>
>> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel) <thomas_os@shipmail.org> wrote:
>>
>> Hi, Zack
>>
>> On 3/11/21 10:07 PM, Zack Rusin wrote:
>>>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) <thomas_os@shipmail.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I tried latest drm-fixes today and saw a lot of these: Fallout from ttm rework?
>>> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was in drm-misc-next in the drm-misc tree for a while but hasn’t been merged for 5.12.
>>>
>>> z
>>>
>> Hmm, yes but doesn't that fix trip the ttm_bo_unpin() dma_resv_assert_held(bo->base.resv)?
> No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be working fine.
>
>
With CONFIG_PROVE_LOCKING=y I see this:

[    7.117145] [drm] FIFO at 0x00000000fe000000 size is 8192 kiB
[    7.117284] [drm] VRAM at 0x00000000e8000000 size is 131072 kiB
[    7.117291] INFO: trying to register non-static key.
[    7.117295] the code is fine but needs lockdep annotation.
[    7.117298] turning off the locking correctness validator

Which will probably mask that dma_resv_assert_held(bo->base.resv)

/Thomas


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-12 10:06       ` Thomas Hellström (Intel)
@ 2021-03-15 17:57         ` Zack Rusin
  2021-03-15 20:38           ` Daniel Vetter
  0 siblings, 1 reply; 12+ messages in thread
From: Zack Rusin @ 2021-03-15 17:57 UTC (permalink / raw)
  To: Thomas Hellström (Intel), dri-devel

On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
> 
> On 3/12/21 12:02 AM, Zack Rusin wrote:
>>
>>> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel) 
>>> <thomas_os@shipmail.org> wrote:
>>>
>>> Hi, Zack
>>>
>>> On 3/11/21 10:07 PM, Zack Rusin wrote:
>>>>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) 
>>>>> <thomas_os@shipmail.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I tried latest drm-fixes today and saw a lot of these: Fallout from 
>>>>> ttm rework?
>>>> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was 
>>>> in drm-misc-next in the drm-misc tree for a while but hasn’t been 
>>>> merged for 5.12.
>>>>
>>>> z
>>>>
>>> Hmm, yes but doesn't that fix trip the ttm_bo_unpin() 
>>> dma_resv_assert_held(bo->base.resv)?
>> No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be 
>> working fine.
>>
>>
> With CONFIG_PROVE_LOCKING=y I see this:
> 
> [    7.117145] [drm] FIFO at 0x00000000fe000000 size is 8192 kiB
> [    7.117284] [drm] VRAM at 0x00000000e8000000 size is 131072 kiB
> [    7.117291] INFO: trying to register non-static key.
> [    7.117295] the code is fine but needs lockdep annotation.
> [    7.117298] turning off the locking correctness validator
> 
> Which will probably mask that dma_resv_assert_held(bo->base.resv)
> 

Ah, yes, you're right. After fixing that I do see the 
dma_resv_assert_held triggered. Technically trivially fixable with 
ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but it's a little 
ugly that some places e.g. vmw_bo_unreference will require 
ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but some won't e.g. 
vmw_mob_destroy won't because its lock is held by ttm_bo_delayed_delete 
without a very clear indication within the function which is which.

z
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-15 17:57         ` Zack Rusin
@ 2021-03-15 20:38           ` Daniel Vetter
  2021-03-15 22:35             ` Thomas Hellström (Intel)
  0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2021-03-15 20:38 UTC (permalink / raw)
  To: Zack Rusin; +Cc: Thomas Hellström (Intel), dri-devel

On Mon, Mar 15, 2021 at 6:57 PM Zack Rusin <zackr@vmware.com> wrote:
>
> On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
> >
> > On 3/12/21 12:02 AM, Zack Rusin wrote:
> >>
> >>> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel)
> >>> <thomas_os@shipmail.org> wrote:
> >>>
> >>> Hi, Zack
> >>>
> >>> On 3/11/21 10:07 PM, Zack Rusin wrote:
> >>>>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel)
> >>>>> <thomas_os@shipmail.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I tried latest drm-fixes today and saw a lot of these: Fallout from
> >>>>> ttm rework?
> >>>> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was
> >>>> in drm-misc-next in the drm-misc tree for a while but hasn’t been
> >>>> merged for 5.12.
> >>>>
> >>>> z
> >>>>
> >>> Hmm, yes but doesn't that fix trip the ttm_bo_unpin()
> >>> dma_resv_assert_held(bo->base.resv)?
> >> No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be
> >> working fine.
> >>
> >>
> > With CONFIG_PROVE_LOCKING=y I see this:
> >
> > [    7.117145] [drm] FIFO at 0x00000000fe000000 size is 8192 kiB
> > [    7.117284] [drm] VRAM at 0x00000000e8000000 size is 131072 kiB
> > [    7.117291] INFO: trying to register non-static key.
> > [    7.117295] the code is fine but needs lockdep annotation.
> > [    7.117298] turning off the locking correctness validator
> >
> > Which will probably mask that dma_resv_assert_held(bo->base.resv)
> >
>
> Ah, yes, you're right. After fixing that I do see the
> dma_resv_assert_held triggered. Technically trivially fixable with
> ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but it's a little
> ugly that some places e.g. vmw_bo_unreference will require
> ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but some won't e.g.
> vmw_mob_destroy won't because its lock is held by ttm_bo_delayed_delete
> without a very clear indication within the function which is which.

Not sure it applies here, but if the refcount is down to 0 we know
we're in destruction code and can't race with anything anymore, so
maybe we can lift the debug check.

Otoh I think at that point we might still be on lru lists, so the
rules become rather tricky whether it's really always legal to skip
the dma_resv_lock. But we could perhaps figure out something if it's
too annoying to have a consistent calling context in drivers.

I'm not a huge fan of dropping the requirement from unpin and
switching to atomic_t for the pin count, since pin/unpin is an
extremely slow path, adding complexity in how we protect stuff for a
function that's maybe called 60/s (for page flipping we pin/unpin)
doesn't strike me as the right balance. And atomic commit helpers are
explicitly designed to allow drivers to grab dma_resv_lock in their
->cleanup_fb hook, since that part is _not_ in the dma_fence
signalling critical path for the atomic flip. But if all else fails I
guess that's an option too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-15 20:38           ` Daniel Vetter
@ 2021-03-15 22:35             ` Thomas Hellström (Intel)
  2021-03-17  1:51               ` Zack Rusin
  0 siblings, 1 reply; 12+ messages in thread
From: Thomas Hellström (Intel) @ 2021-03-15 22:35 UTC (permalink / raw)
  To: Daniel Vetter, Zack Rusin; +Cc: dri-devel


On 3/15/21 9:38 PM, Daniel Vetter wrote:
> On Mon, Mar 15, 2021 at 6:57 PM Zack Rusin <zackr@vmware.com> wrote:
>> On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
>>> On 3/12/21 12:02 AM, Zack Rusin wrote:
>>>>> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel)
>>>>> <thomas_os@shipmail.org> wrote:
>>>>>
>>>>> Hi, Zack
>>>>>
>>>>> On 3/11/21 10:07 PM, Zack Rusin wrote:
>>>>>>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel)
>>>>>>> <thomas_os@shipmail.org> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I tried latest drm-fixes today and saw a lot of these: Fallout from
>>>>>>> ttm rework?
>>>>>> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was
>>>>>> in drm-misc-next in the drm-misc tree for a while but hasn’t been
>>>>>> merged for 5.12.
>>>>>>
>>>>>> z
>>>>>>
>>>>> Hmm, yes but doesn't that fix trip the ttm_bo_unpin()
>>>>> dma_resv_assert_held(bo->base.resv)?
>>>> No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be
>>>> working fine.
>>>>
>>>>
>>> With CONFIG_PROVE_LOCKING=y I see this:
>>>
>>> [    7.117145] [drm] FIFO at 0x00000000fe000000 size is 8192 kiB
>>> [    7.117284] [drm] VRAM at 0x00000000e8000000 size is 131072 kiB
>>> [    7.117291] INFO: trying to register non-static key.
>>> [    7.117295] the code is fine but needs lockdep annotation.
>>> [    7.117298] turning off the locking correctness validator
>>>
>>> Which will probably mask that dma_resv_assert_held(bo->base.resv)
>>>
>> Ah, yes, you're right. After fixing that I do see the
>> dma_resv_assert_held triggered. Technically trivially fixable with
>> ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but it's a little
>> ugly that some places e.g. vmw_bo_unreference will require
>> ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but some won't e.g.
>> vmw_mob_destroy won't because its lock is held by ttm_bo_delayed_delete
>> without a very clear indication within the function which is which.

It looks like, like Daniel hints below, for the mob pagetable bos since 
they are pinned and hence not on a LRU list, the parent bo is holding 
the only reference, which is utilized in vmw_mob_unbind() to make sure 
the tryreserve always succeeds. (unpin could be called in vmw_mob_unbind 
for the pagetable bo just after fencing if necessary), and similarly for 
the other vmwgfx_mob error paths, but in that case one should probably 
keep the bo pointers in stack variables until you know you don't have to 
unpin. Then it should be ok to tryreserve around unpinning in the error 
paths.

But it's constructs like that, that really makes me think we shouldn't 
need to reserve to unpin.

> Not sure it applies here, but if the refcount is down to 0 we know
> we're in destruction code and can't race with anything anymore, so
> maybe we can lift the debug check.
>
> Otoh I think at that point we might still be on lru lists, so the
> rules become rather tricky whether it's really always legal to skip
> the dma_resv_lock. But we could perhaps figure out something if it's
> too annoying to have a consistent calling context in drivers.
>
> I'm not a huge fan of dropping the requirement from unpin and
> switching to atomic_t for the pin count, since pin/unpin is an
> extremely slow path, adding complexity in how we protect stuff for a
> function that's maybe called 60/s (for page flipping we pin/unpin)
> doesn't strike me as the right balance.

*If* we can protect the bo LRU state with the lru lock instead of with 
reservation it shuld probably only be a matter of extending the lru lock 
critical section over a couple of assignments. If we change the bo lru 
state we'd need to grab the lru lock sooner or later anyway, so I think 
the added complexity should be minimal.

/Thomas


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: vmwgfx leaking bo pins?
  2021-03-15 22:35             ` Thomas Hellström (Intel)
@ 2021-03-17  1:51               ` Zack Rusin
  0 siblings, 0 replies; 12+ messages in thread
From: Zack Rusin @ 2021-03-17  1:51 UTC (permalink / raw)
  To: Thomas Hellström (Intel), Daniel Vetter; +Cc: dri-devel

On 3/15/21 6:35 PM, Thomas Hellström (Intel) wrote:
> 
> On 3/15/21 9:38 PM, Daniel Vetter wrote:
>> On Mon, Mar 15, 2021 at 6:57 PM Zack Rusin <zackr@vmware.com> wrote:
>>> On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
>>>> On 3/12/21 12:02 AM, Zack Rusin wrote:
>>>>>> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel)
>>>>>> <thomas_os@shipmail.org> wrote:
>>>>>>
>>>>>> Hi, Zack
>>>>>>
>>>>>> On 3/11/21 10:07 PM, Zack Rusin wrote:
>>>>>>>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel)
>>>>>>>> <thomas_os@shipmail.org> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I tried latest drm-fixes today and saw a lot of these: Fallout from
>>>>>>>> ttm rework?
>>>>>>> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was
>>>>>>> in drm-misc-next in the drm-misc tree for a while but hasn’t been
>>>>>>> merged for 5.12.
>>>>>>>
>>>>>>> z
>>>>>>>
>>>>>> Hmm, yes but doesn't that fix trip the ttm_bo_unpin()
>>>>>> dma_resv_assert_held(bo->base.resv)?
>>>>> No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be
>>>>> working fine.
>>>>>
>>>>>
>>>> With CONFIG_PROVE_LOCKING=y I see this:
>>>>
>>>> [    7.117145] [drm] FIFO at 0x00000000fe000000 size is 8192 kiB
>>>> [    7.117284] [drm] VRAM at 0x00000000e8000000 size is 131072 kiB
>>>> [    7.117291] INFO: trying to register non-static key.
>>>> [    7.117295] the code is fine but needs lockdep annotation.
>>>> [    7.117298] turning off the locking correctness validator
>>>>
>>>> Which will probably mask that dma_resv_assert_held(bo->base.resv)
>>>>
>>> Ah, yes, you're right. After fixing that I do see the
>>> dma_resv_assert_held triggered. Technically trivially fixable with
>>> ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but it's a little
>>> ugly that some places e.g. vmw_bo_unreference will require
>>> ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but some won't e.g.
>>> vmw_mob_destroy won't because its lock is held by ttm_bo_delayed_delete
>>> without a very clear indication within the function which is which.
> 
> It looks like, like Daniel hints below, for the mob pagetable bos since 
> they are pinned and hence not on a LRU list, the parent bo is holding 
> the only reference, which is utilized in vmw_mob_unbind() to make sure 
> the tryreserve always succeeds. (unpin could be called in vmw_mob_unbind 
> for the pagetable bo just after fencing if necessary), 

That's a little tricky because then we'd have to pin on bind, otherwise 
after moves, which unbind, we wouldn't be pinned anymore. Plus bind 
would have to check if the bo is already pinned (i.e. it's the first 
time bind is called on it) since we pin on creation. Or just stop 
pinning on creation and do it explicitly in bind/unbind.

In general we probably should make pinning explicit in vmwgfx like in 
the other drivers because, as is, we sometimes have to treat pin_count 
as a boolean (e.g. in vmw_bo_pin_reserved) because often times the 
object has already been pinned during creation. This will break if we'll 
have drm utilities use pin/unpin.

That's a problem of our own making though, the issue of whether or not 
the bo has already been reserved is a little more muddy because having 
multiple nested pin/unpin sites (as long as they're consistent in their 
matching pin/unpin usage) isn't a problem, but having nested reserved 
calls is a problem. Although this might be a case of an old man yelling 
at the sun because I'm too lazy to remember whether or not each callback 
is already called reserved and instead should just add 
dma_resv_assert_held(bo->resv) in more places to clarify which is which 
or like you mention use tryreserve everywhere.

> But it's constructs like that, that really makes me think we shouldn't 
> need to reserve to unpin.

Yea, that would be pretty convenient.

z
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-03-17  1:51 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-11 10:46 vmwgfx leaking bo pins? Thomas Hellström (Intel)
2021-03-11 11:32 ` AW: " Koenig, Christian
2021-03-11 12:36   ` Thomas Hellström (Intel)
2021-03-11 21:07 ` Zack Rusin
2021-03-11 22:35   ` Thomas Hellström (Intel)
2021-03-11 23:02     ` Zack Rusin
2021-03-12  8:13       ` Christian König
2021-03-12 10:06       ` Thomas Hellström (Intel)
2021-03-15 17:57         ` Zack Rusin
2021-03-15 20:38           ` Daniel Vetter
2021-03-15 22:35             ` Thomas Hellström (Intel)
2021-03-17  1:51               ` Zack Rusin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.