All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: "Ruhl, Michael J" <michael.j.ruhl@intel.com>,
	"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>,
	"airlied@redhat.com" <airlied@redhat.com>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"maarten.lankhorst@linux.intel.com" 
	<maarten.lankhorst@linux.intel.com>,
	"mripard@kernel.org" <mripard@kernel.org>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"sean@poorly.run" <sean@poorly.run>,
	"eric@anholt.net" <eric@anholt.net>,
	"sam@ravnborg.org" <sam@ravnborg.org>
Cc: "linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations
Date: Tue, 12 Jan 2021 08:45:00 +0100	[thread overview]
Message-ID: <65f6679c-dc53-e902-bcd1-a960caef756b@suse.de> (raw)
In-Reply-To: <39d9d40bf6284ef29c777776f9f2b5a3@intel.com>


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

Hi

Am 08.01.21 um 17:12 schrieb Ruhl, Michael J:
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>> Thomas Zimmermann
>> Sent: Friday, January 8, 2021 4:43 AM
>> To: sumit.semwal@linaro.org; christian.koenig@amd.com;
>> airlied@redhat.com; daniel@ffwll.ch; maarten.lankhorst@linux.intel.com;
>> mripard@kernel.org; kraxel@redhat.com; hdegoede@redhat.com;
>> sean@poorly.run; eric@anholt.net; sam@ravnborg.org
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; dri-devel@lists.freedesktop.org;
>> virtualization@lists.linux-foundation.org; linaro-mm-sig@lists.linaro.org;
>> Thomas Zimmermann <tzimmermann@suse.de>; linux-
>> media@vger.kernel.org
>> Subject: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local
>> operations
>>
>> The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
>> allowed to pin the buffer or acquire the buffer's reservation object
>> lock.
>>
>> This is a problem for callers that only require a short-term mapping
>> of the buffer without the pinning, or callers that have special locking
>> requirements. These may suffer from unnecessary overhead or interfere
>> with regular pin operations.
>>
>> The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
>> their rsp callbacks in struct dma_buf_ops provide an alternative without
>> pinning or reservation locking. Callers are responsible for these
>> operations.
>>
>> v4:
>> 	* update documentation (Daniel)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
>> drivers/dma-buf/dma-buf.c | 81
>> +++++++++++++++++++++++++++++++++++++++
>> include/linux/dma-buf.h   | 34 ++++++++++++++++
>> 2 files changed, 115 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index b8465243eca2..01f9c74d97fa 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -1295,6 +1295,87 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>> struct dma_buf_map *map)
>> }
>> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>>
>> +/**
>> + * dma_buf_vmap_local - Create virtual mapping for the buffer object into
>> kernel
>> + * address space.
>> + * @dmabuf:	[in]	buffer to vmap
>> + * @map:	[out]	returns the vmap pointer
>> + *
>> + * Unlike dma_buf_vmap() this is a short term mapping and will not pin
>> + * the buffer. The struct dma_resv for the @dmabuf must be locked until
>> + * dma_buf_vunmap_local() is called.
>> + *
>> + * Returns:
>> + * 0 on success, or a negative errno code otherwise.
>> + */
>> +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>> *map)
>> +{
>> +	struct dma_buf_map ptr;
>> +	int ret = 0;
>> +
>> +	dma_buf_map_clear(map);
>> +
>> +	if (WARN_ON(!dmabuf))
>> +		return -EINVAL;
>> +
>> +	dma_resv_assert_held(dmabuf->resv);
>> +
>> +	if (!dmabuf->ops->vmap_local)
>> +		return -EINVAL;
> 
> You are clearing the map, and then doing the above checks.
> 
> Is it ok to change the map info and then exit on error?

In vmap_local map argument returns the mapping's address. Callers are 
expected to check the return code. But I would expect a careless caller 
to not check, or check for map being cleared. Clearing it here first is 
the save thing to do.

Best regards
Thomas

> 
> Mike
> 
>> +	mutex_lock(&dmabuf->lock);
>> +	if (dmabuf->vmapping_counter) {
>> +		dmabuf->vmapping_counter++;
>> +		BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> +		*map = dmabuf->vmap_ptr;
>> +		goto out_unlock;
>> +	}
>> +
>> +	BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
>> +
>> +	ret = dmabuf->ops->vmap_local(dmabuf, &ptr);
>> +	if (WARN_ON_ONCE(ret))
>> +		goto out_unlock;
>> +
>> +	dmabuf->vmap_ptr = ptr;
>> +	dmabuf->vmapping_counter = 1;
>> +
>> +	*map = dmabuf->vmap_ptr;
>> +
>> +out_unlock:
>> +	mutex_unlock(&dmabuf->lock);
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
>> +
>> +/**
>> + * dma_buf_vunmap_local - Unmap a vmap obtained by
>> dma_buf_vmap_local.
>> + * @dmabuf:	[in]	buffer to vunmap
>> + * @map:	[in]	vmap pointer to vunmap
>> + *
>> + * Release a mapping established with dma_buf_vmap_local().
>> + */
>> +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>> dma_buf_map *map)
>> +{
>> +	if (WARN_ON(!dmabuf))
>> +		return;
>> +
>> +	dma_resv_assert_held(dmabuf->resv);
>> +
>> +	BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> +	BUG_ON(dmabuf->vmapping_counter == 0);
>> +	BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
>> +
>> +	mutex_lock(&dmabuf->lock);
>> +	if (--dmabuf->vmapping_counter == 0) {
>> +		if (dmabuf->ops->vunmap_local)
>> +			dmabuf->ops->vunmap_local(dmabuf, map);
>> +		dma_buf_map_clear(&dmabuf->vmap_ptr);
>> +	}
>> +	mutex_unlock(&dmabuf->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
>> +
>> #ifdef CONFIG_DEBUG_FS
>> static int dma_buf_debug_show(struct seq_file *s, void *unused)
>> {
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index 628681bf6c99..aeed754b5467 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -264,6 +264,38 @@ struct dma_buf_ops {
>>
>> 	int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
>> 	void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +
>> +	/**
>> +	 * @vmap_local:
>> +	 *
>> +	 * Creates a virtual mapping for the buffer into kernel address space.
>> +	 *
>> +	 * This callback establishes short-term mappings for situations where
>> +	 * callers only use the buffer for a bounded amount of time; such as
>> +	 * updates to the framebuffer or reading back contained information.
>> +	 * In contrast to the regular @vmap callback, vmap_local does never
>> pin
>> +	 * the buffer to a specific domain or acquire the buffer's reservation
>> +	 * lock.
>> +	 *
>> +	 * This is called with the &dma_buf.resv object locked. Callers must
>> hold
>> +	 * the lock until after removing the mapping with @vunmap_local.
>> +	 *
>> +	 * This callback is optional.
>> +	 *
>> +	 * Returns:
>> +	 *
>> +	 * 0 on success or a negative error code on failure.
>> +	 */
>> +	int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +
>> +	/**
>> +	 * @vunmap_local:
>> +	 *
>> +	 * Removes a virtual mapping that was established by @vmap_local.
>> +	 *
>> +	 * This callback is optional.
>> +	 */
>> +	void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> };
>>
>> /**
>> @@ -501,4 +533,6 @@ int dma_buf_mmap(struct dma_buf *, struct
>> vm_area_struct *,
>> 		 unsigned long);
>> int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
>> void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>> dma_buf_map *map);
>> #endif /* __DMA_BUF_H__ */
>> --
>> 2.29.2
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: "Ruhl, Michael J" <michael.j.ruhl@intel.com>,
	"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>,
	"airlied@redhat.com" <airlied@redhat.com>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"maarten.lankhorst@linux.intel.com"
	<maarten.lankhorst@linux.intel.com>,
	"mripard@kernel.org" <mripard@kernel.org>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"sean@poorly.run" <sean@poorly.run>,
	"eric@anholt.net" <eric@anholt.net>,
	"sam@ravnborg.org" <sam@ravnborg.org>
Cc: "linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations
Date: Tue, 12 Jan 2021 08:45:00 +0100	[thread overview]
Message-ID: <65f6679c-dc53-e902-bcd1-a960caef756b@suse.de> (raw)
In-Reply-To: <39d9d40bf6284ef29c777776f9f2b5a3@intel.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 7718 bytes --]

Hi

Am 08.01.21 um 17:12 schrieb Ruhl, Michael J:
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>> Thomas Zimmermann
>> Sent: Friday, January 8, 2021 4:43 AM
>> To: sumit.semwal@linaro.org; christian.koenig@amd.com;
>> airlied@redhat.com; daniel@ffwll.ch; maarten.lankhorst@linux.intel.com;
>> mripard@kernel.org; kraxel@redhat.com; hdegoede@redhat.com;
>> sean@poorly.run; eric@anholt.net; sam@ravnborg.org
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; dri-devel@lists.freedesktop.org;
>> virtualization@lists.linux-foundation.org; linaro-mm-sig@lists.linaro.org;
>> Thomas Zimmermann <tzimmermann@suse.de>; linux-
>> media@vger.kernel.org
>> Subject: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local
>> operations
>>
>> The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
>> allowed to pin the buffer or acquire the buffer's reservation object
>> lock.
>>
>> This is a problem for callers that only require a short-term mapping
>> of the buffer without the pinning, or callers that have special locking
>> requirements. These may suffer from unnecessary overhead or interfere
>> with regular pin operations.
>>
>> The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
>> their rsp callbacks in struct dma_buf_ops provide an alternative without
>> pinning or reservation locking. Callers are responsible for these
>> operations.
>>
>> v4:
>> 	* update documentation (Daniel)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
>> drivers/dma-buf/dma-buf.c | 81
>> +++++++++++++++++++++++++++++++++++++++
>> include/linux/dma-buf.h   | 34 ++++++++++++++++
>> 2 files changed, 115 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index b8465243eca2..01f9c74d97fa 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -1295,6 +1295,87 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>> struct dma_buf_map *map)
>> }
>> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>>
>> +/**
>> + * dma_buf_vmap_local - Create virtual mapping for the buffer object into
>> kernel
>> + * address space.
>> + * @dmabuf:	[in]	buffer to vmap
>> + * @map:	[out]	returns the vmap pointer
>> + *
>> + * Unlike dma_buf_vmap() this is a short term mapping and will not pin
>> + * the buffer. The struct dma_resv for the @dmabuf must be locked until
>> + * dma_buf_vunmap_local() is called.
>> + *
>> + * Returns:
>> + * 0 on success, or a negative errno code otherwise.
>> + */
>> +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>> *map)
>> +{
>> +	struct dma_buf_map ptr;
>> +	int ret = 0;
>> +
>> +	dma_buf_map_clear(map);
>> +
>> +	if (WARN_ON(!dmabuf))
>> +		return -EINVAL;
>> +
>> +	dma_resv_assert_held(dmabuf->resv);
>> +
>> +	if (!dmabuf->ops->vmap_local)
>> +		return -EINVAL;
> 
> You are clearing the map, and then doing the above checks.
> 
> Is it ok to change the map info and then exit on error?

In vmap_local map argument returns the mapping's address. Callers are 
expected to check the return code. But I would expect a careless caller 
to not check, or check for map being cleared. Clearing it here first is 
the save thing to do.

Best regards
Thomas

> 
> Mike
> 
>> +	mutex_lock(&dmabuf->lock);
>> +	if (dmabuf->vmapping_counter) {
>> +		dmabuf->vmapping_counter++;
>> +		BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> +		*map = dmabuf->vmap_ptr;
>> +		goto out_unlock;
>> +	}
>> +
>> +	BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
>> +
>> +	ret = dmabuf->ops->vmap_local(dmabuf, &ptr);
>> +	if (WARN_ON_ONCE(ret))
>> +		goto out_unlock;
>> +
>> +	dmabuf->vmap_ptr = ptr;
>> +	dmabuf->vmapping_counter = 1;
>> +
>> +	*map = dmabuf->vmap_ptr;
>> +
>> +out_unlock:
>> +	mutex_unlock(&dmabuf->lock);
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
>> +
>> +/**
>> + * dma_buf_vunmap_local - Unmap a vmap obtained by
>> dma_buf_vmap_local.
>> + * @dmabuf:	[in]	buffer to vunmap
>> + * @map:	[in]	vmap pointer to vunmap
>> + *
>> + * Release a mapping established with dma_buf_vmap_local().
>> + */
>> +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>> dma_buf_map *map)
>> +{
>> +	if (WARN_ON(!dmabuf))
>> +		return;
>> +
>> +	dma_resv_assert_held(dmabuf->resv);
>> +
>> +	BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> +	BUG_ON(dmabuf->vmapping_counter == 0);
>> +	BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
>> +
>> +	mutex_lock(&dmabuf->lock);
>> +	if (--dmabuf->vmapping_counter == 0) {
>> +		if (dmabuf->ops->vunmap_local)
>> +			dmabuf->ops->vunmap_local(dmabuf, map);
>> +		dma_buf_map_clear(&dmabuf->vmap_ptr);
>> +	}
>> +	mutex_unlock(&dmabuf->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
>> +
>> #ifdef CONFIG_DEBUG_FS
>> static int dma_buf_debug_show(struct seq_file *s, void *unused)
>> {
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index 628681bf6c99..aeed754b5467 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -264,6 +264,38 @@ struct dma_buf_ops {
>>
>> 	int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
>> 	void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +
>> +	/**
>> +	 * @vmap_local:
>> +	 *
>> +	 * Creates a virtual mapping for the buffer into kernel address space.
>> +	 *
>> +	 * This callback establishes short-term mappings for situations where
>> +	 * callers only use the buffer for a bounded amount of time; such as
>> +	 * updates to the framebuffer or reading back contained information.
>> +	 * In contrast to the regular @vmap callback, vmap_local does never
>> pin
>> +	 * the buffer to a specific domain or acquire the buffer's reservation
>> +	 * lock.
>> +	 *
>> +	 * This is called with the &dma_buf.resv object locked. Callers must
>> hold
>> +	 * the lock until after removing the mapping with @vunmap_local.
>> +	 *
>> +	 * This callback is optional.
>> +	 *
>> +	 * Returns:
>> +	 *
>> +	 * 0 on success or a negative error code on failure.
>> +	 */
>> +	int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +
>> +	/**
>> +	 * @vunmap_local:
>> +	 *
>> +	 * Removes a virtual mapping that was established by @vmap_local.
>> +	 *
>> +	 * This callback is optional.
>> +	 */
>> +	void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> };
>>
>> /**
>> @@ -501,4 +533,6 @@ int dma_buf_mmap(struct dma_buf *, struct
>> vm_area_struct *,
>> 		 unsigned long);
>> int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
>> void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>> dma_buf_map *map);
>> #endif /* __DMA_BUF_H__ */
>> --
>> 2.29.2
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: "Ruhl, Michael J" <michael.j.ruhl@intel.com>,
	"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>,
	"airlied@redhat.com" <airlied@redhat.com>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"maarten.lankhorst@linux.intel.com"
	<maarten.lankhorst@linux.intel.com>,
	"mripard@kernel.org" <mripard@kernel.org>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"sean@poorly.run" <sean@poorly.run>,
	"eric@anholt.net" <eric@anholt.net>,
	"sam@ravnborg.org" <sam@ravnborg.org>
Cc: "linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations
Date: Tue, 12 Jan 2021 08:45:00 +0100	[thread overview]
Message-ID: <65f6679c-dc53-e902-bcd1-a960caef756b@suse.de> (raw)
In-Reply-To: <39d9d40bf6284ef29c777776f9f2b5a3@intel.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 7718 bytes --]

Hi

Am 08.01.21 um 17:12 schrieb Ruhl, Michael J:
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>> Thomas Zimmermann
>> Sent: Friday, January 8, 2021 4:43 AM
>> To: sumit.semwal@linaro.org; christian.koenig@amd.com;
>> airlied@redhat.com; daniel@ffwll.ch; maarten.lankhorst@linux.intel.com;
>> mripard@kernel.org; kraxel@redhat.com; hdegoede@redhat.com;
>> sean@poorly.run; eric@anholt.net; sam@ravnborg.org
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; dri-devel@lists.freedesktop.org;
>> virtualization@lists.linux-foundation.org; linaro-mm-sig@lists.linaro.org;
>> Thomas Zimmermann <tzimmermann@suse.de>; linux-
>> media@vger.kernel.org
>> Subject: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local
>> operations
>>
>> The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
>> allowed to pin the buffer or acquire the buffer's reservation object
>> lock.
>>
>> This is a problem for callers that only require a short-term mapping
>> of the buffer without the pinning, or callers that have special locking
>> requirements. These may suffer from unnecessary overhead or interfere
>> with regular pin operations.
>>
>> The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
>> their rsp callbacks in struct dma_buf_ops provide an alternative without
>> pinning or reservation locking. Callers are responsible for these
>> operations.
>>
>> v4:
>> 	* update documentation (Daniel)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
>> drivers/dma-buf/dma-buf.c | 81
>> +++++++++++++++++++++++++++++++++++++++
>> include/linux/dma-buf.h   | 34 ++++++++++++++++
>> 2 files changed, 115 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index b8465243eca2..01f9c74d97fa 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -1295,6 +1295,87 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>> struct dma_buf_map *map)
>> }
>> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>>
>> +/**
>> + * dma_buf_vmap_local - Create virtual mapping for the buffer object into
>> kernel
>> + * address space.
>> + * @dmabuf:	[in]	buffer to vmap
>> + * @map:	[out]	returns the vmap pointer
>> + *
>> + * Unlike dma_buf_vmap() this is a short term mapping and will not pin
>> + * the buffer. The struct dma_resv for the @dmabuf must be locked until
>> + * dma_buf_vunmap_local() is called.
>> + *
>> + * Returns:
>> + * 0 on success, or a negative errno code otherwise.
>> + */
>> +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>> *map)
>> +{
>> +	struct dma_buf_map ptr;
>> +	int ret = 0;
>> +
>> +	dma_buf_map_clear(map);
>> +
>> +	if (WARN_ON(!dmabuf))
>> +		return -EINVAL;
>> +
>> +	dma_resv_assert_held(dmabuf->resv);
>> +
>> +	if (!dmabuf->ops->vmap_local)
>> +		return -EINVAL;
> 
> You are clearing the map, and then doing the above checks.
> 
> Is it ok to change the map info and then exit on error?

In vmap_local map argument returns the mapping's address. Callers are 
expected to check the return code. But I would expect a careless caller 
to not check, or check for map being cleared. Clearing it here first is 
the save thing to do.

Best regards
Thomas

> 
> Mike
> 
>> +	mutex_lock(&dmabuf->lock);
>> +	if (dmabuf->vmapping_counter) {
>> +		dmabuf->vmapping_counter++;
>> +		BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> +		*map = dmabuf->vmap_ptr;
>> +		goto out_unlock;
>> +	}
>> +
>> +	BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
>> +
>> +	ret = dmabuf->ops->vmap_local(dmabuf, &ptr);
>> +	if (WARN_ON_ONCE(ret))
>> +		goto out_unlock;
>> +
>> +	dmabuf->vmap_ptr = ptr;
>> +	dmabuf->vmapping_counter = 1;
>> +
>> +	*map = dmabuf->vmap_ptr;
>> +
>> +out_unlock:
>> +	mutex_unlock(&dmabuf->lock);
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
>> +
>> +/**
>> + * dma_buf_vunmap_local - Unmap a vmap obtained by
>> dma_buf_vmap_local.
>> + * @dmabuf:	[in]	buffer to vunmap
>> + * @map:	[in]	vmap pointer to vunmap
>> + *
>> + * Release a mapping established with dma_buf_vmap_local().
>> + */
>> +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>> dma_buf_map *map)
>> +{
>> +	if (WARN_ON(!dmabuf))
>> +		return;
>> +
>> +	dma_resv_assert_held(dmabuf->resv);
>> +
>> +	BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> +	BUG_ON(dmabuf->vmapping_counter == 0);
>> +	BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
>> +
>> +	mutex_lock(&dmabuf->lock);
>> +	if (--dmabuf->vmapping_counter == 0) {
>> +		if (dmabuf->ops->vunmap_local)
>> +			dmabuf->ops->vunmap_local(dmabuf, map);
>> +		dma_buf_map_clear(&dmabuf->vmap_ptr);
>> +	}
>> +	mutex_unlock(&dmabuf->lock);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
>> +
>> #ifdef CONFIG_DEBUG_FS
>> static int dma_buf_debug_show(struct seq_file *s, void *unused)
>> {
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index 628681bf6c99..aeed754b5467 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -264,6 +264,38 @@ struct dma_buf_ops {
>>
>> 	int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
>> 	void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +
>> +	/**
>> +	 * @vmap_local:
>> +	 *
>> +	 * Creates a virtual mapping for the buffer into kernel address space.
>> +	 *
>> +	 * This callback establishes short-term mappings for situations where
>> +	 * callers only use the buffer for a bounded amount of time; such as
>> +	 * updates to the framebuffer or reading back contained information.
>> +	 * In contrast to the regular @vmap callback, vmap_local does never
>> pin
>> +	 * the buffer to a specific domain or acquire the buffer's reservation
>> +	 * lock.
>> +	 *
>> +	 * This is called with the &dma_buf.resv object locked. Callers must
>> hold
>> +	 * the lock until after removing the mapping with @vunmap_local.
>> +	 *
>> +	 * This callback is optional.
>> +	 *
>> +	 * Returns:
>> +	 *
>> +	 * 0 on success or a negative error code on failure.
>> +	 */
>> +	int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +
>> +	/**
>> +	 * @vunmap_local:
>> +	 *
>> +	 * Removes a virtual mapping that was established by @vmap_local.
>> +	 *
>> +	 * This callback is optional.
>> +	 */
>> +	void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> };
>>
>> /**
>> @@ -501,4 +533,6 @@ int dma_buf_mmap(struct dma_buf *, struct
>> vm_area_struct *,
>> 		 unsigned long);
>> int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
>> void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>> *map);
>> +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>> dma_buf_map *map);
>> #endif /* __DMA_BUF_H__ */
>> --
>> 2.29.2
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 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

  reply	other threads:[~2021-01-12  7:45 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08  9:43 [PATCH v4 00/13] drm: Support short-term vmap via vmap_local Thomas Zimmermann
2021-01-08  9:43 ` Thomas Zimmermann
2021-01-08  9:43 ` Thomas Zimmermann
2021-01-08  9:43 ` [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08 16:12   ` Ruhl, Michael J
2021-01-08 16:12     ` Ruhl, Michael J
2021-01-12  7:45     ` Thomas Zimmermann [this message]
2021-01-12  7:45       ` Thomas Zimmermann
2021-01-12  7:45       ` Thomas Zimmermann
2021-01-14 14:39       ` Ruhl, Michael J
2021-01-14 14:39         ` Ruhl, Michael J
2021-01-08  9:43 ` [PATCH v4 02/13] drm/gem: Create infrastructure for GEM vmap_local Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43 ` [PATCH v4 03/13] drm/cma-helper: Provide a vmap function for short-term mappings Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43 ` [PATCH v4 04/13] drm/shmem-helper: " Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-11 16:50   ` Daniel Vetter
2021-01-11 16:50     ` Daniel Vetter
2021-01-11 16:50     ` Daniel Vetter
2021-01-12 13:11     ` Thomas Zimmermann
2021-01-12 13:11       ` Thomas Zimmermann
2021-01-12 13:11       ` Thomas Zimmermann
2021-01-12 14:16       ` Daniel Vetter
2021-01-12 14:16         ` Daniel Vetter
2021-01-12 14:16         ` Daniel Vetter
2021-01-27 12:08     ` Thomas Zimmermann
2021-01-27 12:08       ` Thomas Zimmermann
2021-01-27 12:08       ` Thomas Zimmermann
2021-02-02 14:11       ` Daniel Vetter
2021-02-02 14:11         ` Daniel Vetter
2021-02-02 14:11         ` Daniel Vetter
2021-01-08  9:43 ` [PATCH v4 05/13] drm/mgag200: Use drm_gem_shmem_vmap_local() in damage handling Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-11 16:53   ` Daniel Vetter
2021-01-11 16:53     ` Daniel Vetter
2021-01-11 16:53     ` Daniel Vetter
2021-01-11 16:58     ` Daniel Vetter
2021-01-11 16:58       ` Daniel Vetter
2021-01-11 16:58       ` Daniel Vetter
2021-01-08  9:43 ` [PATCH v4 06/13] drm/cirrus: " Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-11 17:00   ` Daniel Vetter
2021-01-11 17:00     ` Daniel Vetter
2021-01-11 17:00     ` Daniel Vetter
2021-01-11 17:03     ` Daniel Vetter
2021-01-11 17:03       ` Daniel Vetter
2021-01-11 17:03       ` Daniel Vetter
2021-01-08  9:43 ` [PATCH v4 07/13] drm/gm12u320: " Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-11 17:01   ` Daniel Vetter
2021-01-11 17:01     ` Daniel Vetter
2021-01-11 17:01     ` Daniel Vetter
2021-01-08  9:43 ` [PATCH v4 08/13] drm/udl: " Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43 ` [PATCH v4 09/13] drm/vram-helper: Provide a vmap function for short-term mappings Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43 ` [PATCH v4 10/13] drm/ast: Use drm_gem_vram_vmap_local() in cursor update Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43 ` [PATCH v4 11/13] drm/vboxvideo: " Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-11 17:06   ` Daniel Vetter
2021-01-11 17:06     ` Daniel Vetter
2021-01-11 17:06     ` Daniel Vetter
2021-01-12  7:54     ` Thomas Zimmermann
2021-01-12  7:54       ` Thomas Zimmermann
2021-01-12  7:54       ` Thomas Zimmermann
2021-01-12  9:17       ` Daniel Vetter
2021-01-12  9:17         ` Daniel Vetter
2021-01-12  9:17         ` Daniel Vetter
2021-01-12  9:53         ` Thomas Zimmermann
2021-01-12  9:53           ` Thomas Zimmermann
2021-01-12  9:53           ` Thomas Zimmermann
2021-01-08  9:43 ` [PATCH v4 12/13] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-08  9:43 ` [PATCH v4 13/13] drm/vram-helper: Remove unused drm_gem_vram_{vmap,vunmap}() Thomas Zimmermann
2021-01-08  9:43   ` [PATCH v4 13/13] drm/vram-helper: Remove unused drm_gem_vram_{vmap, vunmap}() Thomas Zimmermann
2021-01-08  9:43   ` Thomas Zimmermann
2021-01-11 16:52   ` [PATCH v4 13/13] drm/vram-helper: Remove unused drm_gem_vram_{vmap,vunmap}() Daniel Vetter
2021-01-11 16:52     ` Daniel Vetter
2021-01-11 16:52     ` Daniel Vetter

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=65f6679c-dc53-e902-bcd1-a960caef756b@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=hdegoede@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=michael.j.ruhl@intel.com \
    --cc=mripard@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sean@poorly.run \
    --cc=sumit.semwal@linaro.org \
    --cc=virtualization@lists.linux-foundation.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 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.