[PATCH 1/2] memblock: add assertion for zero allocation size

[PATCH 1/2] memblock: add assertion for zero allocation size

[Vineet Gupta]

This came to light when calling memblock allocator from arc port (for
copying flattended DT). If a "0" alignment is passed, the allocator
round_up() call incorrectly rounds up the size to 0.

round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1

While the obvious allocation failure causes kernel to panic, it is
better to BUG_ON() if effective size for allocation (as passed by caller
and/or computed after alignemtn rounding) is zero.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/memblock.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 1bcd9b9..32b36d0 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -824,6 +824,8 @@ static phys_addr_t __init memblock_alloc_base_nid(phys_addr_t size,
 	/* align @size to avoid excessive fragmentation on reserved array */
 	size = round_up(size, align);
 
+	BUG_ON(!size);
+
 	found = memblock_find_in_range_node(0, max_addr, size, align, nid);
 	if (found && !memblock_reserve(found, size))
 		return found;
-- 
1.7.4.1

Re: [PATCH 1/2] memblock: add assertion for zero allocation size

[Yinghai Lu]

[+Cc: hpa]

On Thu, Feb 21, 2013 at 10:39 AM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> This came to light when calling memblock allocator from arc port (for
> copying flattended DT). If a "0" alignment is passed, the allocator
> round_up() call incorrectly rounds up the size to 0.
>
> round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1
>
> While the obvious allocation failure causes kernel to panic, it is
> better to BUG_ON() if effective size for allocation (as passed by caller
> and/or computed after alignemtn rounding) is zero.

should we just make align to 1 instead of 0 ?

or BUG_ON(!align) instead?

>
> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  mm/memblock.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 1bcd9b9..32b36d0 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -824,6 +824,8 @@ static phys_addr_t __init memblock_alloc_base_nid(phys_addr_t size,
>         /* align @size to avoid excessive fragmentation on reserved array */
>         size = round_up(size, align);
>
> +       BUG_ON(!size);
> +
>         found = memblock_find_in_range_node(0, max_addr, size, align, nid);
>         if (found && !memblock_reserve(found, size))
>                 return found;
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] memblock: add assertion for zero allocation size

[Vineet Gupta]

On Friday 22 February 2013 12:57 AM, Yinghai Lu wrote:
> [+Cc: hpa]
>
> On Thu, Feb 21, 2013 at 10:39 AM, Vineet Gupta
> <Vineet.Gupta1@synopsys.com> wrote:
>> This came to light when calling memblock allocator from arc port (for
>> copying flattended DT). If a "0" alignment is passed, the allocator
>> round_up() call incorrectly rounds up the size to 0.
>>
>> round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1
>>
>> While the obvious allocation failure causes kernel to panic, it is
>> better to BUG_ON() if effective size for allocation (as passed by caller
>> and/or computed after alignemtn rounding) is zero.
> should we just make align to 1 instead of 0 ?

Where - you mean if user passes 0, just make it 1. Nah - it's better to complain
and get the call site fixed !

> or BUG_ON(!align) instead?

That could be done too but you would also need BUG_ON(!size) - to catch another
API abuse.
BUG_ON(!size) however catches both the cases.


>
>> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Tejun Heo <tj@kernel.org>
>> Cc: Yinghai Lu <yinghai@kernel.org>
>> Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  mm/memblock.c |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index 1bcd9b9..32b36d0 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -824,6 +824,8 @@ static phys_addr_t __init memblock_alloc_base_nid(phys_addr_t size,
>>         /* align @size to avoid excessive fragmentation on reserved array */
>>         size = round_up(size, align);
>>
>> +       BUG_ON(!size);
>> +
>>         found = memblock_find_in_range_node(0, max_addr, size, align, nid);
>>         if (found && !memblock_reserve(found, size))
>>                 return found;
>> --
>> 1.7.4.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] memblock: add assertion for zero allocation size

[Tejun Heo]

On Fri, Feb 22, 2013 at 01:03:41AM +0530, Vineet Gupta wrote:
> Where - you mean if user passes 0, just make it 1. Nah - it's better to complain
> and get the call site fixed !
> 
> > or BUG_ON(!align) instead?
> 
> That could be done too but you would also need BUG_ON(!size) - to catch another
> API abuse.
> BUG_ON(!size) however catches both the cases.

How about "if (WARN_ON(!align)) align = __alignof__(long long);"?
Early BUG_ON()s can be painful to debug depending on setup.

Thanks.

-- 
tejun

Re: [PATCH 1/2] memblock: add assertion for zero allocation size

[Vineet Gupta]

On Friday 22 February 2013 01:06 AM, Tejun Heo wrote:
> On Fri, Feb 22, 2013 at 01:03:41AM +0530, Vineet Gupta wrote:
>> Where - you mean if user passes 0, just make it 1. Nah - it's better to complain
>> and get the call site fixed !
>>
>>> or BUG_ON(!align) instead?
>> That could be done too but you would also need BUG_ON(!size) - to catch another
>> API abuse.
>> BUG_ON(!size) however catches both the cases.
> How about "if (WARN_ON(!align)) align = __alignof__(long long);"?
> Early BUG_ON()s can be painful to debug depending on setup.

Totally agree - been there - seen that :-)
Also for caller passing zero, the panic will force the caller to fix it.
I'll respin the patch.

Thx,
-Vineet

[PATCH v2 1/2] memblock: add assertion for zero allocation alignment

[Vineet Gupta]

This came to light when calling memblock allocator from arc port (for
copying flattended DT). If a "0" alignment is passed, the allocator
round_up() call incorrectly rounds up the size to 0.

round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1

While the obvious allocation failure causes kernel to panic, it is
better to warn the caller to fix the code.

Tejun suggested that instead of BUG_ON(!align) - which might be
ineffective due to pending console init and such, it is better to
WARN_ON, and continue the boot with a reasonable default align.

Caller passing @size need not be handled similarly as the subsequent
panic will indicate that anyhow.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/memblock.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 1bcd9b9..f3804bd 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -824,6 +824,9 @@ static phys_addr_t __init memblock_alloc_base_nid(phys_addr_t size,
 	/* align @size to avoid excessive fragmentation on reserved array */
 	size = round_up(size, align);
 
+	if (WARN_ON(!align))
+		align = __alignof__(long long);
+
 	found = memblock_find_in_range_node(0, max_addr, size, align, nid);
 	if (found && !memblock_reserve(found, size))
 		return found;
-- 
1.7.4.1

Re: [PATCH v2 1/2] memblock: add assertion for zero allocation alignment

[Yinghai Lu]

On Thu, Feb 21, 2013 at 12:10 PM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> This came to light when calling memblock allocator from arc port (for
> copying flattended DT). If a "0" alignment is passed, the allocator
> round_up() call incorrectly rounds up the size to 0.
>
> round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1
>
> While the obvious allocation failure causes kernel to panic, it is
> better to warn the caller to fix the code.
>
> Tejun suggested that instead of BUG_ON(!align) - which might be
> ineffective due to pending console init and such, it is better to
> WARN_ON, and continue the boot with a reasonable default align.
>
> Caller passing @size need not be handled similarly as the subsequent
> panic will indicate that anyhow.
>
> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  mm/memblock.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 1bcd9b9..f3804bd 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -824,6 +824,9 @@ static phys_addr_t __init memblock_alloc_base_nid(phys_addr_t size,
>         /* align @size to avoid excessive fragmentation on reserved array */
>         size = round_up(size, align);
>
> +       if (WARN_ON(!align))
> +               align = __alignof__(long long);
> +

the checking should be put before round_up?

>         found = memblock_find_in_range_node(0, max_addr, size, align, nid);
>         if (found && !memblock_reserve(found, size))
>                 return found;
> --
> 1.7.4.1
>

Re: [PATCH v2 1/2] memblock: add assertion for zero allocation alignment

[Vineet Gupta]

On Friday 22 February 2013 02:01 AM, Yinghai Lu wrote:
> On Thu, Feb 21, 2013 at 12:10 PM, Vineet Gupta
> <Vineet.Gupta1@synopsys.com> wrote:
>> This came to light when calling memblock allocator from arc port (for
>> copying flattended DT). If a "0" alignment is passed, the allocator
>> round_up() call incorrectly rounds up the size to 0.
>>
>> round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1
>>
>> While the obvious allocation failure causes kernel to panic, it is
>> better to warn the caller to fix the code.
>>
>> Tejun suggested that instead of BUG_ON(!align) - which might be
>> ineffective due to pending console init and such, it is better to
>> WARN_ON, and continue the boot with a reasonable default align.
>>
>> Caller passing @size need not be handled similarly as the subsequent
>> panic will indicate that anyhow.
>>
>> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Tejun Heo <tj@kernel.org>
>> Cc: Yinghai Lu <yinghai@kernel.org>
>> Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  mm/memblock.c |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index 1bcd9b9..f3804bd 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -824,6 +824,9 @@ static phys_addr_t __init memblock_alloc_base_nid(phys_addr_t size,
>>         /* align @size to avoid excessive fragmentation on reserved array */
>>         size = round_up(size, align);
>>
>> +       if (WARN_ON(!align))
>> +               align = __alignof__(long long);
>> +
> the checking should be put before round_up?

Oops my bad.

Interestingly however, I did test this exact patch on ARC before sending out -
passing @align = 0 to make it hit the WARN. It prints the warning, and uses
@size=0, @align=8 for memblock_find_in_range_node() and successfully allocates
memory as opposed to failure for @size=0, @align=0 scenario. This is kind of weird.

Anyhow I'll send the updated patch to fix the gotcha !

Thx,
-Vineet

[PATCH v3 1/2] memblock: add assertion for zero allocation alignment

[Vineet Gupta]

This came to light when calling memblock allocator from arc port (for
copying flattended DT). If a "0" alignment is passed, the allocator
round_up() call incorrectly rounds up the size to 0.

round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1

While the obvious allocation failure causes kernel to panic, it is
better to warn the caller to fix the code.

Tejun suggested that instead of BUG_ON(!align) - which might be
ineffective due to pending console init and such, it is better to
WARN_ON, and continue the boot with a reasonable default align.

Caller passing @size need not be handled similarly as the subsequent
panic will indicate that anyhow.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/memblock.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 1bcd9b9..8080cf8 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -821,6 +821,9 @@ static phys_addr_t __init memblock_alloc_base_nid(phys_addr_t size,
 {
 	phys_addr_t found;
 
+	if (WARN_ON(!align))
+		align = __alignof__(long long);
+
 	/* align @size to avoid excessive fragmentation on reserved array */
 	size = round_up(size, align);
 
-- 
1.7.4.1

Re: [PATCH v3 1/2] memblock: add assertion for zero allocation alignment

[Tejun Heo]

On Thu, Feb 21, 2013 at 12:52 PM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> This came to light when calling memblock allocator from arc port (for
> copying flattended DT). If a "0" alignment is passed, the allocator
> round_up() call incorrectly rounds up the size to 0.
>
> round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1
>
> While the obvious allocation failure causes kernel to panic, it is
> better to warn the caller to fix the code.
>
> Tejun suggested that instead of BUG_ON(!align) - which might be
> ineffective due to pending console init and such, it is better to
> WARN_ON, and continue the boot with a reasonable default align.
>
> Caller passing @size need not be handled similarly as the subsequent
> panic will indicate that anyhow.
>
> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org

Acked-by: Tejun Heo <tj@kernel.org>

Thanks.

-- 
tejun

Re: [PATCH v3 1/2] memblock: add assertion for zero allocation alignment

[Vineet Gupta]

Hi Andrew,

On Friday 22 February 2013 02:23 AM, Tejun Heo wrote:
> On Thu, Feb 21, 2013 at 12:52 PM, Vineet Gupta
> <Vineet.Gupta1@synopsys.com> wrote:
>> This came to light when calling memblock allocator from arc port (for
>> copying flattended DT). If a "0" alignment is passed, the allocator
>> round_up() call incorrectly rounds up the size to 0.
>>
>> round_up(num, alignto) => ((num - 1) | (alignto -1)) + 1
>>
>> While the obvious allocation failure causes kernel to panic, it is
>> better to warn the caller to fix the code.
>>
>> Tejun suggested that instead of BUG_ON(!align) - which might be
>> ineffective due to pending console init and such, it is better to
>> WARN_ON, and continue the boot with a reasonable default align.
>>
>> Caller passing @size need not be handled similarly as the subsequent
>> panic will indicate that anyhow.
>>
>> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Tejun Heo <tj@kernel.org>
>> Cc: Yinghai Lu <yinghai@kernel.org>
>> Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
> 
> Acked-by: Tejun Heo <tj@kernel.org>
> 
> Thanks.
> 

I'm hoping this will be routed via the mm tree.

Thx,
-Vineet

[PATCH 2/2] xtensa: Flat DeviceTree copy not future-safe

[Vineet Gupta]

flat DT copy code calls bootmem allocator with @align = 0.
This is probably OK with legacy allocator which xtensa uses right now,
but this will panic right away with memblock allocator

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Marc Gauthier <marc@tensilica.com>
Cc: linux-xtensa@linux-xtensa.org
Cc: linux-kernel@vger.kernel.org
---
 arch/xtensa/kernel/setup.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index 6dd25ec..c2a526e 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -256,7 +256,7 @@ void __init early_init_devtree(void *params)
 static void __init copy_devtree(void)
 {
 	void *alloc = early_init_dt_alloc_memory_arch(
-			be32_to_cpu(initial_boot_params->totalsize), 0);
+			be32_to_cpu(initial_boot_params->totalsize), 8);
 	if (alloc) {
 		memcpy(alloc, initial_boot_params,
 				be32_to_cpu(initial_boot_params->totalsize));
-- 
1.7.4.1

Re: [PATCH 2/2] xtensa: Flat DeviceTree copy not future-safe

[Max Filippov]

On Thu, Feb 21, 2013 at 10:39 PM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> flat DT copy code calls bootmem allocator with @align = 0.
> This is probably OK with legacy allocator which xtensa uses right now,
> but this will panic right away with memblock allocator
>
> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Cc: Marc Gauthier <marc@tensilica.com>
> Cc: linux-xtensa@linux-xtensa.org
> Cc: linux-kernel@vger.kernel.org

Acked-by: Max Filippov <jcmvbkbc@gmail.com>

-- 
Thanks.
-- Max

Fwd: [PATCH 2/2] xtensa: Flat DeviceTree copy not future-safe

[Vineet Gupta]

Hi Max,

This patch - acked by you then, got lost in the mist of time. Care to take it in
via xtensa tree for 3.11

Thx,
-Vineet


-------- Original Message --------
Subject: [PATCH 2/2] xtensa: Flat DeviceTree copy not future-safe
Date: Fri, 22 Feb 2013 00:09:22 +0530
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Andrew Morton <akpm@linux-foundation.org>, Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>, Marc Gauthier <marc@tensilica.com>
CC: Vineet Gupta <Vineet.Gupta1@synopsys.com>, <linux-xtensa@linux-xtensa.org>,
<linux-kernel@vger.kernel.org>
Newsgroups: gmane.linux.kernel
References: <1361471962-25164-1-git-send-email-vgupta@synopsys.com>

flat DT copy code calls bootmem allocator with @align = 0.
This is probably OK with legacy allocator which xtensa uses right now,
but this will panic right away with memblock allocator

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Marc Gauthier <marc@tensilica.com>
Cc: linux-xtensa@linux-xtensa.org
Cc: linux-kernel@vger.kernel.org
---
 arch/xtensa/kernel/setup.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index 6dd25ec..c2a526e 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -256,7 +256,7 @@ void __init early_init_devtree(void *params)
 static void __init copy_devtree(void)
 {
 	void *alloc = early_init_dt_alloc_memory_arch(
-			be32_to_cpu(initial_boot_params->totalsize), 0);
+			be32_to_cpu(initial_boot_params->totalsize), 8);
 	if (alloc) {
 		memcpy(alloc, initial_boot_params,
 				be32_to_cpu(initial_boot_params->totalsize));
-- 
1.7.4.1

Re: [PATCH 2/2] xtensa: Flat DeviceTree copy not future-safe

[Max Filippov]

Hi Vineet,

On Wed, May 29, 2013 at 5:10 PM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> Hi Max,
>
> This patch - acked by you then, got lost in the mist of time. Care to take it in
> via xtensa tree for 3.11

Oops. Thanks for the reminder. Took it to the xtensa-fixes branch.

> -------- Original Message --------
> Subject: [PATCH 2/2] xtensa: Flat DeviceTree copy not future-safe
> Date: Fri, 22 Feb 2013 00:09:22 +0530
> From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
> To: Andrew Morton <akpm@linux-foundation.org>, Chris Zankel <chris@zankel.net>,
> Max Filippov <jcmvbkbc@gmail.com>, Marc Gauthier <marc@tensilica.com>
> CC: Vineet Gupta <Vineet.Gupta1@synopsys.com>, <linux-xtensa@linux-xtensa.org>,
> <linux-kernel@vger.kernel.org>
> Newsgroups: gmane.linux.kernel
> References: <1361471962-25164-1-git-send-email-vgupta@synopsys.com>

-- 
Thanks.
-- Max