mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@redhat.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	airlied@gmail.com, daniel@ffwll.ch, matthew.brost@intel.com,
	sarah.walker@imgtec.com, donald.robson@imgtec.com,
	boris.brezillon@collabora.com, christian.koenig@amd.com,
	faith@gfxstrand.net
Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH drm-misc-next v5 4/6] drm/gpuvm: track/lock/validate external/evicted objects
Date: Wed, 4 Oct 2023 14:57:08 +0200	[thread overview]
Message-ID: <6489f31f-8929-3e59-fbef-a22049cccbe3@redhat.com> (raw)
In-Reply-To: <6b16ab6f-b1a2-efdb-04bf-5af4c3de381b@linux.intel.com>

On 10/3/23 11:11, Thomas Hellström wrote:

<snip>

>>> +
>>> +/**
>>> + * drm_gpuvm_bo_evict() - add / remove a &drm_gpuvm_bo to / from the &drm_gpuvms
>>> + * evicted list
>>> + * @vm_bo: the &drm_gpuvm_bo to add or remove
>>> + * @evict: indicates whether the object is evicted
>>> + *
>>> + * Adds a &drm_gpuvm_bo to or removes it from the &drm_gpuvms evicted list.
>>> + */
>>> +void
>>> +drm_gpuvm_bo_evict(struct drm_gpuvm_bo *vm_bo, bool evict)
>>> +{
>>> +    struct drm_gem_object *obj = vm_bo->obj;
>>> +
>>> +    dma_resv_assert_held(obj->resv);
>>> +
>>> +    /* Always lock list transactions, even if DRM_GPUVM_RESV_PROTECTED is
>>> +     * set. This is required to protect multiple concurrent calls to
>>> +     * drm_gpuvm_bo_evict() with BOs with different dma_resv.
>>> +     */
>>
>> This doesn't work. The RESV_PROTECTED case requires the evicted flag we discussed before. The list is either protected by the spinlock or the resv. Otherwise a list add could race with a list removal elsewhere.

I think it does unless I miss something, but it might be a bit subtle though.

Concurrent drm_gpuvm_bo_evict() are protected by the spinlock. Additionally, when
drm_gpuvm_bo_evict() is called we hold the dma-resv of the corresponding GEM object.

In drm_gpuvm_validate() I assert that we hold *all* dma-resv, which implies that no
one can call drm_gpuvm_bo_evict() on any of the VM's objects and no one can add a new
one and directly call drm_gpuvm_bo_evict() on it either.

>>
>> Thanks,
>>
>> Thomas
>>
>>
> 


  reply	other threads:[~2023-10-04 12:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28 19:16 [PATCH drm-misc-next v5 0/6] [RFC] DRM GPUVM features Danilo Krummrich
2023-09-28 19:16 ` [PATCH drm-misc-next v5 1/6] drm/gpuvm: add common dma-resv per struct drm_gpuvm Danilo Krummrich
2023-09-28 19:16 ` [PATCH drm-misc-next v5 2/6] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm Danilo Krummrich
2023-09-28 19:16 ` [PATCH drm-misc-next v5 3/6] drm/gpuvm: add an abstraction for a VM / BO combination Danilo Krummrich
2023-10-02  6:34   ` kernel test robot
2023-10-05 11:51   ` Thomas Hellström
2023-10-08 23:08     ` Danilo Krummrich
2023-09-28 19:16 ` [PATCH drm-misc-next v5 4/6] drm/gpuvm: track/lock/validate external/evicted objects Danilo Krummrich
2023-10-02 15:40   ` kernel test robot
2023-10-03  8:36   ` Thomas Hellström
2023-10-03  9:11     ` Thomas Hellström
2023-10-04 12:57       ` Danilo Krummrich [this message]
2023-10-04 15:29         ` Thomas Hellström
2023-10-04 17:17           ` Danilo Krummrich
2023-10-04 17:57             ` Thomas Hellström
2023-10-04 18:24               ` Danilo Krummrich
2023-10-03 10:05     ` Boris Brezillon
2023-10-03 12:25       ` Thomas Hellström
2023-10-03 14:21         ` Boris Brezillon
2023-10-03 16:55           ` Danilo Krummrich
2023-10-03 17:37             ` Thomas Hellström
2023-10-04 13:35               ` Danilo Krummrich
2023-10-03 18:57             ` Thomas Hellström
2023-10-05 11:55   ` Thomas Hellström
2023-09-28 19:16 ` [PATCH drm-misc-next v5 5/6] drm/nouveau: make use of the GPUVM's shared dma-resv Danilo Krummrich
2023-09-28 19:16 ` [PATCH drm-misc-next v5 6/6] drm/nouveau: use GPUVM common infrastructure Danilo Krummrich
2023-10-05  9:35 ` [PATCH drm-misc-next v5 0/6] [RFC] DRM GPUVM features Thomas Hellström
2023-10-08 22:48   ` Danilo Krummrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6489f31f-8929-3e59-fbef-a22049cccbe3@redhat.com \
    --to=dakr@redhat.com \
    --cc=airlied@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=donald.robson@imgtec.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=faith@gfxstrand.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=sarah.walker@imgtec.com \
    --cc=thomas.hellstrom@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome