Re: [PATCH v2] of: Check for overlap in reserved memory regions

[Michael Ellerman <mpe@ellerman.id.au>]

On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:

> Any overlap in the reserved memory regions (those specified in the
> reserved-memory DT node) is a bug.  These bugs might go undetected as
> long as the contested region isn't used simultaneously by multiple
> software agents, which makes such bugs hard to debug.  Fix this by
> printing a scary warning during boot if overlap is detected.
> 
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 726ebe792813..62f467b8ccae 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -197,12 +198,52 @@ static int __init __reserved_mem_init_node(struct reserved_mem *rmem)
>  	return -ENOENT;
>  }
>  
> +static int __init __rmem_cmp(const void *a, const void *b)
> +{
> +	const struct reserved_mem *ra = a, *rb = b;
> +
> +	return ra->base - rb->base;
> +}

So on further inspection it seems this is really our problem.

The reserved_mem->base values are u64, so when the unsigned result of the
substraction is converted to int we may or may not get the right value. That
means the sort fails and the reserved mem check gives false positives.

eg:

  Reserved memory: OVERLAP DETECTED!
  ibm,slw-image@1ffe600000 (0x0000001ffe600000--0x0000001ffe700000) overlaps with ibm,firmware-allocs-memory@1000000000 (0x0000001000000000--0x0000001000dc0200)

Note there is no overlap:

  0x0000001ffe600000--0x0000001ffe700000
  vs
  0x0000001000000000--0x0000001000dc0200

cheers