[PATCH] drm/mm: Document locking rules

[PATCH] drm/mm: Document locking rules

[Daniel Vetter]

Drivers need to take care. Motivated by a discussion between Mark and
Rob on dri-devel.

Cc: Mark yao <mark.yao@rock-chips.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_mm.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index ca1e344f318d..6109e022e000 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -89,6 +89,11 @@
  *
  * Finally iteration helpers to walk all nodes and all holes are provided as are
  * some basic allocator dumpers for debugging.
+ *
+ * Note that this range allocator is not thread-safe, drivers need to protect
+ * allocation and freeing with their on locking. The idea behind this is that
+ * for a full memory manager additional data needs to be protected anyway, hence
+ * internal locking would be fully redundant.
  */
 
 static struct drm_mm_node *drm_mm_search_free_generic(const struct drm_mm *mm,
-- 
2.7.4

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

Re: [PATCH] drm/mm: Document locking rules

[Chris Wilson]

On Tue, Dec 27, 2016 at 11:10:57AM +0100, Daniel Vetter wrote:
> Drivers need to take care. Motivated by a discussion between Mark and
> Rob on dri-devel.
> 
> Cc: Mark yao <mark.yao@rock-chips.com>
> Cc: Rob Clark <robdclark@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_mm.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index ca1e344f318d..6109e022e000 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -89,6 +89,11 @@
>   *
>   * Finally iteration helpers to walk all nodes and all holes are provided as are
>   * some basic allocator dumpers for debugging.
> + *
> + * Note that this range allocator is not thread-safe, drivers need to protect
> + * allocation and freeing with their on locking. The idea behind this is that
> + * for a full memory manager additional data needs to be protected anyway, hence
> + * internal locking would be fully redundant.
>   */

I was going to write the same after that question, the only difference
is trying to avoid using the terms allocation/freeing (since it
doesn't!) - probably just replace both with "modification".

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/mm: Document locking rules

[Daniel Vetter]

Drivers need to take care. Motivated by a discussion between Mark and
Rob on dri-devel.

Cc: Mark yao <mark.yao@rock-chips.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_mm.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index ca1e344f318d..6109e022e000 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -89,6 +89,11 @@
  *
  * Finally iteration helpers to walk all nodes and all holes are provided as are
  * some basic allocator dumpers for debugging.
+ *
+ * Note that this range allocator is not thread-safe, drivers need to protect
+ * allocation and freeing with their on locking. The idea behind this is that
+ * for a full memory manager additional data needs to be protected anyway, hence
+ * internal locking would be fully redundant.
  */
 
 static struct drm_mm_node *drm_mm_search_free_generic(const struct drm_mm *mm,
-- 
2.7.4

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