linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de,
	mripard@kernel.org, corbet@lwn.net, christian.koenig@amd.com,
	bskeggs@redhat.com, Liam.Howlett@oracle.com,
	matthew.brost@intel.com, alexdeucher@gmail.com,
	ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org,
	jason@jlekstrand.net, dri-devel@lists.freedesktop.org,
	nouveau@lists.freedesktop.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Donald Robson <donald.robson@imgtec.com>,
	Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings
Date: Fri, 7 Jul 2023 13:00:10 +0200	[thread overview]
Message-ID: <20230707130010.1bd5d41b@collabora.com> (raw)
In-Reply-To: <20230629222651.3196-3-dakr@redhat.com>

On Fri, 30 Jun 2023 00:25:18 +0200
Danilo Krummrich <dakr@redhat.com> wrote:

> +/**
> + * drm_gpuva_for_each_va_range - iternator to walk over a range of &drm_gpuvas
> + * @va__: &drm_gpuva structure to assign to in each iteration step
> + * @mgr__: &drm_gpuva_manager to walk over
> + * @start__: starting offset, the first gpuva will overlap this
> + * @end__: ending offset, the last gpuva will start before this (but may
> + * overlap)
> + *
> + * This iterator walks over all &drm_gpuvas in the &drm_gpuva_manager that lie
> + * between @start__ and @end__. It is implemented similarly to list_for_each(),
> + * but is using the &drm_gpuva_manager's internal interval tree to accelerate
> + * the search for the starting &drm_gpuva, and hence isn't safe against removal
> + * of elements. It assumes that @end__ is within (or is the upper limit of) the
> + * &drm_gpuva_manager. This iterator does not skip over the &drm_gpuva_manager's
> + * @kernel_alloc_node.
> + */
> +#define drm_gpuva_for_each_va_range(va__, mgr__, start__, end__) \
> +	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__)); \

drm_gpuva_find_first() takes the range size as its last argument, not
the range end:

	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__) - (start__)); \


> +	     va__ && (va__->va.addr < (end__)) && \
> +	     !list_entry_is_head(va__, &(mgr__)->rb.list, rb.entry); \
> +	     va__ = list_next_entry(va__, rb.entry))

If you define:

static inline struct drm_gpuva *
drm_gpuva_next(struct drm_gpuva *va)
{
	if (va && !list_is_last(&va->rb.entry, &va->mgr->rb.list))
		return list_next_entry(va, rb.entry);

	return NULL;
}

the for loop becomes a bit more readable:

	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__) - (start__)); \
	     va__ && (va__->va.addr < (end__)); \
	     va__ = drm_gpuva_next(va__))

> +
> +/**
> + * drm_gpuva_for_each_va_range_safe - iternator to safely walk over a range of
> + * &drm_gpuvas
> + * @va__: &drm_gpuva to assign to in each iteration step
> + * @next__: another &drm_gpuva to use as temporary storage
> + * @mgr__: &drm_gpuva_manager to walk over
> + * @start__: starting offset, the first gpuva will overlap this
> + * @end__: ending offset, the last gpuva will start before this (but may
> + * overlap)
> + *
> + * This iterator walks over all &drm_gpuvas in the &drm_gpuva_manager that lie
> + * between @start__ and @end__. It is implemented similarly to
> + * list_for_each_safe(), but is using the &drm_gpuva_manager's internal interval
> + * tree to accelerate the search for the starting &drm_gpuva, and hence is safe
> + * against removal of elements. It assumes that @end__ is within (or is the
> + * upper limit of) the &drm_gpuva_manager. This iterator does not skip over the
> + * &drm_gpuva_manager's @kernel_alloc_node.
> + */
> +#define drm_gpuva_for_each_va_range_safe(va__, next__, mgr__, start__, end__) \
> +	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__)), \
> +	     next__ = va ? list_next_entry(va__, rb.entry) : NULL; \
> +	     va__ && (va__->va.addr < (end__)) && \
> +	     !list_entry_is_head(va__, &(mgr__)->rb.list, rb.entry); \
> +	     va__ = next__, next__ = list_next_entry(va__, rb.entry))

And this is the safe version using the drm_gpuva_next() helper:

	for (va__ = drm_gpuva_find_first((mgr__), (start__), (end__) - (start__)), \
	     next__ = drm_gpuva_next(va__); \
	     va__ && (va__->va.addr < (end__)); \
	     va__ = next__, next__ = drm_gpuva_next(va__))

Those changes fixed an invalid pointer access I had in the sm_unmap()
path.

  parent reply	other threads:[~2023-07-07 11:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-29 22:25 [PATCH drm-next v6 00/13] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 01/13] drm: execution context for GEM buffers v5 Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings Danilo Krummrich
2023-06-30  8:02   ` Boris Brezillon
2023-06-30  8:09     ` Boris Brezillon
2023-06-30  9:40     ` Boris Brezillon
2023-07-06 15:06     ` Danilo Krummrich
2023-07-06 16:17       ` Boris Brezillon
2023-07-06  8:49   ` Thomas Hellström (Intel)
2023-07-06 15:45   ` Donald Robson
2023-07-06 15:52     ` Danilo Krummrich
2023-07-06 18:26   ` Boris Brezillon
2023-07-07  7:57     ` Boris Brezillon
2023-07-07 12:32       ` Danilo Krummrich
2023-07-07 11:00   ` Boris Brezillon [this message]
2023-07-07 12:41     ` Danilo Krummrich
2023-07-07 12:52       ` Boris Brezillon
2023-07-08  6:39         ` Matthew Brost
2023-06-29 22:25 ` [PATCH drm-next v6 03/13] drm: debugfs: provide infrastructure to dump a DRM GPU VA space Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 04/13] drm/nouveau: new VM_BIND uapi interfaces Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 05/13] drm/nouveau: get vmm via nouveau_cli_vmm() Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 06/13] drm/nouveau: bo: initialize GEM GPU VA interface Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 07/13] drm/nouveau: move usercopy helpers to nouveau_drv.h Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 08/13] drm/nouveau: fence: separate fence alloc and emit Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 09/13] drm/nouveau: fence: fail to emit when fence context is killed Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 10/13] drm/nouveau: chan: provide nouveau_channel_kill() Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 11/13] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 12/13] drm/nouveau: implement new VM_BIND uAPI Danilo Krummrich
2023-06-29 22:25 ` [PATCH drm-next v6 13/13] drm/nouveau: debugfs: implement DRM GPU VA debugfs 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=20230707130010.1bd5d41b@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=airlied@gmail.com \
    --cc=airlied@redhat.com \
    --cc=alexdeucher@gmail.com \
    --cc=bagasdotme@gmail.com \
    --cc=bskeggs@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=dakr@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=donald.robson@imgtec.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ogabbay@kernel.org \
    --cc=tzimmermann@suse.de \
    --cc=willy@infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).