[PATCH] drm/mm: Document locking rules

Chris Wilson chris at chris-wilson.co.uk
Wed Dec 28 11:14:19 UTC 2016


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 at rock-chips.com>
> Cc: Rob Clark <robdclark at gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at 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 at chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the dri-devel mailing list