From patchwork Mon Feb 24 16:58:57 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= X-Patchwork-Id: 3710671 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id C0C379F2F7 for ; Mon, 24 Feb 2014 17:00:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D1ED320154 for ; Mon, 24 Feb 2014 17:00:24 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D3709200E5 for ; Mon, 24 Feb 2014 17:00:23 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WHysk-0005SG-Si; Mon, 24 Feb 2014 16:59:55 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WHysi-0003aP-E6; Mon, 24 Feb 2014 16:59:52 +0000 Received: from metis.ext.pengutronix.de ([2001:6f8:1178:4:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WHysf-0003Yl-Ja for linux-arm-kernel@lists.infradead.org; Mon, 24 Feb 2014 16:59:50 +0000 Received: from ukl by metis.ext.pengutronix.de with local (Exim 4.72) (envelope-from ) id 1WHyru-0000Qk-QZ; Mon, 24 Feb 2014 17:59:03 +0100 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= To: Dmitry Eremin-Solenikov , Artem Bityutskiy Date: Mon, 24 Feb 2014 17:58:57 +0100 Message-Id: <1393261137-12088-1-git-send-email-u.kleine-koenig@pengutronix.de> X-Mailer: git-send-email 1.9.0 MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ukl@pengutronix.de X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Subject: [PATCH RESEND] mtd: fix bug in partition size calculation related to MTDPART_OFS_RETAIN X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on metis.ext.pengutronix.de) X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140224_115949_994214_9B1F2304 X-CRM114-Status: GOOD ( 17.57 ) X-Spam-Score: -1.9 (-) Cc: David Woodhouse , linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP If the remaining space is exactly what should still be available after the partition in question is added slave->mtd.size was set to zero instead of erroring out. In the next code block this was then interpreted as MTDPART_SIZ_FULL filling the rest of the partition instead of keeping it free for the next partition. This problem existed since the MTDPART_OFS_RETAIN feature was introduced for 3.2-rc1. Fixes: 1a31368bf92e ("mtd: add a flags for partitions which should just leave smth. after them") Signed-off-by: Uwe Kleine-König --- Hello, resending with the correct email address of Artem. This MTDPART_OFS_RETAIN feature looks very special, and there is only a single user (arch/arm/mach-ep93xx/ts72xx.c). Moreover I didn't understand its purpose from reading the documentation in include/linux/mtd/partitions.h: offset: absolute starting position within the master MTD device; [...] if [defined as] MTDPART_OFS_RETAIN, consume as much as possible, leaving size after the end of partition. But maybe it's only me. Anyhow I wonder if this feature is still considered valuable and if it's maybe better to just drop support for MTDPART_OFS_RETAIN. A more intuive replacement could be to specify start and end(+1) of partitions and interpret .start = -0x100000 as 1 MiB before the end of the device. Best regards Uwe drivers/mtd/mtdpart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c index 6e732c3820c1..3ca9d7fbf126 100644 --- a/drivers/mtd/mtdpart.c +++ b/drivers/mtd/mtdpart.c @@ -442,16 +442,16 @@ static struct mtd_part *allocate_partition(struct mtd_info *master, } if (slave->offset == MTDPART_OFS_RETAIN) { slave->offset = cur_offset; - if (master->size - slave->offset >= slave->mtd.size) { + if (master->size - slave->offset > slave->mtd.size) { slave->mtd.size = master->size - slave->offset - slave->mtd.size; } else { printk(KERN_ERR "mtd partition \"%s\" doesn't have enough space: %#llx < %#llx, disabled\n", part->name, master->size - slave->offset, slave->mtd.size); /* register to preserve ordering */ goto out_register; } } if (slave->mtd.size == MTDPART_SIZ_FULL) slave->mtd.size = master->size - slave->offset;