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
| ||
|
Date: Thu, 4 Jul 2019 12:17:48 -0700 From: Chia-I Wu <olvaffe@...il.com> To: Gerd Hoffmann <kraxel@...hat.com> Cc: ML dri-devel <dri-devel@...ts.freedesktop.org>, Gurchetan Singh <gurchetansingh@...omium.org>, David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>, "open list:VIRTIO GPU DRIVER" <virtualization@...ts.linux-foundation.org>, open list <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v6 06/18] drm/virtio: remove ttm calls from in virtio_gpu_object_{reserve,unreserve} On Thu, Jul 4, 2019 at 4:10 AM Gerd Hoffmann <kraxel@...hat.com> wrote: > > Hi, > > > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > > Can you elaborate a bit about how TTM keeps the BOs alive in, for > > example, virtio_gpu_transfer_from_host_ioctl? In that function, only > > three TTM functions are called: ttm_bo_reserve, ttm_bo_validate, and > > ttm_bo_unreserve. I am curious how they keep the BO alive. > > It can't go away between reserve and unreserve, and I think it also > can't be evicted then. Havn't checked how ttm implements that. Hm, but the vbuf using the BO outlives the reserve/unreserve section. The NO_EVICT flag applies only when the BO is still alive. Someone needs to hold a reference to the BO to keep it alive, otherwise the BO can go away before the vbuf is retired. I can be wrong, but on the other hand, it seems fine for a BO to go away before the vbuf using it is retired. When that happens, the driver emits a RESOURCE_UNREF vbuf which is *after* the original vbuf. > > cheers, > Gerd >
Powered by blists - more mailing lists