3.6.11.9-rc1 stable review patch. If anyone has any objections, please let me know. ------------------ From: Wladislav Wiebe <wladislav.kw@xxxxxxxxx> [ Upstream commit 9e40127526e857fa3f29d51e83277204fbdfc6ba ] Already existing property flags are filled wrong for properties created from initial FDT. This could cause problems if this DYNAMIC device-tree functions are used later, i.e. properties are attached/detached/replaced. Simply dumping flags from the running system show, that some initial static (not allocated via kzmalloc()) nodes are marked as dynamic. I putted some debug extensions to property_proc_show(..) : .. + if (OF_IS_DYNAMIC(pp)) + pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n"); + if (OF_IS_DETACHED(pp)) + pr_err("DEBUG: xxx : OF_IS_DETACHED\n"); when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you will see that those flags are filled wrong, basically in most cases it will dump a DYNAMIC or DETACHED status, which is in not true. (BTW. this OF_IS_DETACHED is a own define for debug purposes which which just make a test_bit(OF_DETACHED, &x->_flags) If nodes are dynamic kernel is allowed to kfree() them. But it will crash attempting to do so on the nodes from FDT -- they are not allocated via kzmalloc(). Signed-off-by: Wladislav Wiebe <wladislav.kw@xxxxxxxxx> Acked-by: Alexander Sverdlin <alexander.sverdlin@xxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Signed-off-by: Rob Herring <rob.herring@xxxxxxxxxxx> Signed-off-by: Steven Rostedt <rostedt@xxxxxxxxxxx> --- drivers/of/fdt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 91a375f..17fad3b 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -390,6 +390,8 @@ static void __unflatten_device_tree(struct boot_param_header *blob, mem = (unsigned long) dt_alloc(size + 4, __alignof__(struct device_node)); + memset((void *)mem, 0, size); + ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef); pr_debug(" unflattening %lx...\n", mem); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html