From patchwork Mon Aug 12 11:06:53 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wladislav Wiebe X-Patchwork-Id: 266489 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [IPv6:::1]) by ozlabs.org (Postfix) with ESMTP id 8ABA42C01D6 for ; Mon, 12 Aug 2013 21:09:04 +1000 (EST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id E94BF2C00EC for ; Mon, 12 Aug 2013 21:08:35 +1000 (EST) Received: by mail-wi0-f181.google.com with SMTP id en1so1538955wid.14 for ; Mon, 12 Aug 2013 04:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/xhYnGwMZIrg9dt4WmVToJfHPjZtAsX37DKT5UVB5Ns=; b=vtPgKkT37mBYb4Nop2NmuPOKMxbjHC4KnuoF0coh2FRhMBAW2/aZ+VmYXnt1ijgK8Y T/LvFVDOPjPrfNaqGQ/iVNlWsYR0UYK/yLZb/jW/uE6ddqOclDHCOVDJkHJsBsnLSpk8 gn2n1wDTelDjxZBs5eBh39tNbaF0E1pTPHUDlzxbCmVXVvISAVYFMQvLG/hMQgPmsLHF WxUVchCJHrz7HhnjrLMwXhin+tGE3iHA6mN/pCiHEmiGl7osVgjnriCuDcNWvT/iM3Cl 8YyTjcD5Axvf9ATYrEyZJhsXyiVdBbJNYmjdMf2raYrX2KS8Pvh6AgWQ3+VtkE7bUmE+ CpQA== X-Received: by 10.195.12.170 with SMTP id er10mr12390228wjd.5.1376305706835; Mon, 12 Aug 2013 04:08:26 -0700 (PDT) Received: from [0.0.0.0] ([62.159.77.164]) by mx.google.com with ESMTPSA id z2sm15646783wiv.11.2013.08.12.04.08.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 04:08:26 -0700 (PDT) Message-ID: <5208C1CD.3040601@gmail.com> Date: Mon, 12 Aug 2013 13:06:53 +0200 From: Wladislav Wiebe User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Aaro Koskinen Subject: Re: mm/slab: ppc: ubi: kmalloc_slab WARNING / PPC + UBI driver References: <51F8F827.6020108@gmail.com> <20130731173434.GA27470@blackmetal.musicnaut.iki.fi> In-Reply-To: <20130731173434.GA27470@blackmetal.musicnaut.iki.fi> Cc: dedekind1@gmail.com, dwmw2@infradead.org, penberg@kernel.org, linux-mm@kvack.org, linux-mtd@lists.infradead.org, cl@linux.com, linuxppc-dev@lists.ozlabs.org X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi guys, we got the real root cause of the allocation issue: Subject: [PATCH 1/1] of: fdt: fix memory initialization for expanded DT 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 --- drivers/of/fdt.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- 1.7.1 This is committed to the mainline - hope it comes in soon. Thanks & BR, Wladislav Wiebe On 31/07/13 19:34, Aaro Koskinen wrote: > Hi, > > On Wed, Jul 31, 2013 at 01:42:31PM +0200, Wladislav Wiebe wrote: >> DEBUG: xxx kmalloc_slab, requested 'size' = 8388608, KMALLOC_MAX_SIZE = 4194304 > [...] >> [ccd3be60] [c0099fd4] kmalloc_slab+0x48/0xe8 (unreliable) >> [ccd3be70] [c00ae650] __kmalloc+0x20/0x1b4 >> [ccd3be90] [c00d46f4] seq_read+0x2a4/0x540 >> [ccd3bee0] [c00fe09c] proc_reg_read+0x5c/0x90 >> [ccd3bef0] [c00b4e1c] vfs_read+0xa4/0x150 >> [ccd3bf10] [c00b500c] SyS_read+0x4c/0x84 >> [ccd3bf40] [c000be80] ret_from_syscall+0x0/0x3c > > It seems some procfs file is trying to dump 8 MB at a single go. You > need to fix that to return data in smaller chunks. What file is it? > > A. > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 6bb7cf2..b10ba00 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -392,6 +392,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);