[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